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NOTATION 

A list of the symbols used throughout this document and their definitions is provided below 
for convenience. 

Roman Symbols 


a . . . speed of sound 

cj . . . skin friction coefficient 

c r . . . gas specific heat at constant pressure 

c r . . . gas specific heat at constant volume 

( . . . total internal energy 

/ . . . first grid index of numerical solution 

j . , , second grid index of numerical solut ion 

A*. . . third grid index of numerical solution or thermal conductivity 
k . . . t urbulent kinetic energy 
/ . . . Van Driest damping function 

n . . . rotational speed (revolutions per second) or time step level 
p . . . pressure 

r . . . radius or radial coordinate 
t . . . time 

r } velocity in the (’artesian coordinate system x direction 

r . . . velocity in the (’artesian coordinate system y direction 

zv . . . velocity in the (’artesian coordinate system z direction 

r,. ... velocity in the cylindrical coordinate system radial direction 

r 0 ... velocity in the cylindrical coordinate system circumferential direction 

u\ f i . . . relative velocity in the circumferential direction (= - /w) 

.r . . . Cartesian coordinate system coordinate 
;/... (artesian coordinate system coordinate 
- . .. (artesian coordinate system coordinate 
.1+ . . . turbulence model constant 

ADPA('()7 ... Advanced Ducted Propfan Analysis (ode Version 07 
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ADPERF . . . ADPAO post processing program for propellers 
ADS PI N . . . ADPAC post ])rocessing program 
APPL . . . NASA Application Portable Parallel Library 
ASCII . . . American Standard Code for Information Interchange 
CEL . . . Courant.-Freidrichs-Lewv number (A t/ &t ma x, s tnbu ) 

D . . . diameter 

T . . . i coordinate direction flux vector 
FAST ... NASA Flow Analysis Software Toolkit 
G . . . j coordinate direction flux vector 

GRIDGEN ... Multiple block general purpose mesh generation system 
(VtfOOV Y . . - Treatment groove mesh generation program 
H ... k coordinate direction flux vector 
II total * • • total enthalpy 
J . . . advance ratio (J = U/nD) 

JERRYC ... TRAF2D Airfoil Cascade (/-Mesh Generation Program 
K . . . cylindrical coordinate system source vector 
L . . . reference length 
M . . . Mach number 

M AK ' EADGRID . . . ADPAC multiple- block mesh assembly program 
MI LAC ... NASA-Lewis Compressor Mesh Generation Program 
N . . . Number of blades 
Q . . . vector of conserved variables 
P . . . turbulence kinetic energy production term 

PATCH FINDER ... Multiple block mesh boundary data file construction routine 
PLOTWD . . . NASA graphics flow visulaization program 
Pv . . . gas Prandtl Number 

R . . . gas constant or residual or maximum radius 
7 Z . . . t urbulent Reynolds number 
R( . . . Reynolds Number 
S . . . surface area normal vector 

SDBLIB . . . Scientific DataBase Library (binary file I/O routines) 

T . . . Temperature 

TRAF2D . . . TRAF2D Navier-Stokes analysis code 
TRAF'iD . . . TRAF3D Navier-Stokes analysis code 
TO MC . . . TRAF2D Airfoil Cascade (/-Mesh Generation Program 

V ... Freest ream velocity (units of length/time) 

V . . . volume 


Greek Symbols 

7 . . . specific heat ratio 

A . . . calculation increment 

c . . . turbulence dissipation parameter 

V . . . gradient vector operator 

oj . . . vorticity 

p... density 

// . . . coefficient of viscosity 
r . . . fict it ons time or shear stress 
II ij . . . fluid stress tensor 
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Subscripts 


[ ]i ... inlet value 
[ ] 2 . . . exit value 

[ ]«r • « • pertaining to the axial (,r) cylindrical coordinate 
[ ] t - W M*.sr * * • coarse mesh value 
[ ]?f jfctivf * * • effective value 
[ ]jj Vf . . . fine mesh value 

[ \jv,,su;,u, f roost ream value 

[ . . . grid point index of variable 

laminar flow value 
[ . . . maximum value 

[ . . . minimum value 

[ ]„„„•.(■„// • • • near wall value 
[ ] n o„-, a,,,',,*' o,ml ■ ■ • non-dimensional value 

[ ], pertaining to the radial (/■) cylindrical coordinate 

reference value 

[ }sttthh • • ■ value implied by linear stability 
[ ] t . . . t urbulent flow value 
[ ] totfl{ . . . total (stagnation) value 
[ ]turbuhnt ••• turbulent flow value 
[ ]iraii * * • value at the wall 

[ ] ; pertaining to the x ('artesian coordinate 

[ . pertaining to the ij Cartesian coordinate 

[]„... pertaining to the c Cartesian coordinate 
[ ]^ . . . pertaining to the circumferential ( 0 ) cylindrical coordinate 

Superscripts 

[ ]+ . . . Turbulent velocity profile coordinate 
[ ]* . . . Intermediate value 
[ ]" . . . Time step index 

[ ] . . . (no overscore) nondimensional variable 
[ ] . . . Dimensional variable 
[ ] . . . Time-averaged variable 
[ ] . . . Density- weighted time- averaged variable 
[ ] . . . Vector variable 
[ ] . . . Tensor variable 
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Chapter 1 

SUMMARY 


The overall objective of this study was to develop a 3-1) numerical analysis for compressor 
casing treatment flowfields, and to perform a series of detailed numerical predictions to 
assess the effectiveness of various end wall treatments for enhancing the efficiency and stall 
margin of modern high speed fan rotors. Particular attention was given to examining the 
effectiveness of end wall treatments to counter the undesirable effects of inflow distortion. 
The motivation behind this study was the relative lack of physical understanding of the 
mechanics associated with the effects of end wall treatments and the availability of detailed 
computational fluid dynamics ((’FI)) codes which might be utilized to gain a better under- 
standing of these flows. The current version of the computer codes resulting from this study 
are referred to as A I)l > A('()l ( Advanced Ducted Propfan Analysis ( ’odes- Version 7). This 
report is intended to serve as a computer program user's manual for the A I)PA('()7 code de- 
veloped under Tasks VI and \ II ol NASA Contract NAS3-2>270. The A I) PA ( 01 program 
is based on a flexible multiple-block grid discretization scheme permitting coupled 2-D/3-1) 
mesh block solutions with application to a wide variety of geometries. Aerodynamic calcula- 
tions are based on a four-stage Runge-Kutta time-marching finite volume solution technique 
with added numerical dissipation. Steady flow predictions are accelerated by a multigrid 
procedure. The consolidated code generated during this study is capable of executing in 
either a serial or parallel computing mode from a single source code. 
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Chapter 2 

INTRODUCTION 


This document contains the Computer Program User s Manual lot the consolidated AD- 
PA CO 7 (Advanced Ducted Propfan Analysis Codes - Version 7) Euler/Xavier-Stokes anal- 
ysis developed by the Allison Engine ( ompany under lasts VI and VII of NASA Con- 
tract XAS3-25270. The objective of the development of the ADPAC series ol codes was 
to develop a three-dimensional time-marching Euler/ N avier-Stokes analysis for aerody- 
namic/heat transfer analysis of modern turbomachinery flow configurations. The analysis is 
capable of predicting both steady state and time-dependent flow fields using coupled 2-D/3- 
D solution zooming concepts (described in detail in Section 2.3). I he consolidated code 
was developed to be capable of either serial execution or parallel execution on massively 
parallel or workstation cluster computing platforms from a single source. The serial/ parallel 
execution capability is determined at compilation. Ihroughout the rest- of this document, 
the' aerodynamic analysis is referred to as ADPAC 07 to signify that il is veision < of the 
.1 DPA (' series of codes. 

A t heoretical development of the ADPAC07 program is outlined in the Final Report for 
Task VII of NASA Contract NAS3-25270 [21]. Additional information is presented in the 
Final Reports for Tasks V [-1] and VIII [3] of NASA Contract NAS3-25270. In brief, the 
program utilizes a finite- volume, time-marching numerical procedure in conjunction with a 
flexible, coupled 2- 1) /3-D multiple grid block geometric representation to permit detailed 
aerodynamic simulations about complex configurations. The analysis has been tested and 
results verified for both turbomachinery and non-t urbomachinery based applications. The 
ability to accurately predict the aerodynamics due to the interactions between adjacent 
components of modern, high-speed t urbomachinery' was of particular inteiest during this 
program, and therefore, emphasis is given to these types of calculations throughout the 
remainder of this document. It should be emphasized at this point that although the 
ADPAC07 program was developed to analyze the steady and unsteady aerodynamics of 
high-bypass ducted fans employing multiple blade rows, the code possesses many features 
which make it practical to compute a number of other complicated flow configurations as 
well. 


2.1 Multiple-Block Solution Domain Concepts 

In order to appreciate and utilize the feat ures of the .1 DPA ('07 solut ion system, the concept 
of a multiple-block grid system must be fully understood. It is expected that the reader 
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possesses at least some understanding of the concepts of computational fluid dynamics 
(CFD). so the use of a numerical grid to discretize a flow domain should not be foreign. 
Many CFD analyses rely on a single structured ordering of grid points upon which the 
numerical solution is performed. Multiple-block grid systems are different only in that 
several structured grid systems are used in harmony to generate the numerical solution. 
This concept is illustrated graphically in two dimensions for the flow through a nozzle in 
Figures 2. 1-2.3. 

The grid system in Figure 2.1 employs a single structured ordering, resulting in a sin- 
gle computational space to contend with. The mesh system in Figure 2.2 is comprised of 
two. separate structured grid blocks, and consequently, the numerical solution consists of 
two unique computational domains. In theory, the nozzle flowpath could be subdivided into 
any number of domains employing structured grid blocks resulting in an identical number of 
computational domains to contend with, as shown in the 20 block decomposition illustrated 
in Figure 2.3. The complicating factor in this domain decomposition approach is that the 
numerical solution must provide a means for the isolated computational domains to com- 
municate with each other in order to satisfy the conservation laws governing the desired 
aerodynamic solution. Hence, as the number of subdomains used to complete the aerody- 
namic solution grows larger, the number of inter-domain communication pat hs increases in a 
corresponding manner. (It should be noted that this domain decomposition/communication 
overhead relationship is also a key concept in parallel processing for large scale computa- 
tions, and thus, the ADPAC07 code possesses a natural domain decomposition division for 
parallel processing afforded by the multiple-block grid data structure.) 

For the simple nozzle case illustrated in Figure 2.1 it would seem that there is no real 
advantage in using a multiple-block grid, and this is probably true. For more complicated 
geometries, such as the turbine vane coupled O-H grid system shown in Figure 2.4 and the 
corresponding computational domain communication scheme shown in Figure 2.5. it may 
not be possible to generate a single structured grid to encompass the domain of interest 
without sacrificing grid quality, and therefore, a multiple-block grid system has significant 
ad vant ages. 

The ADPAC07 code utilizes the multiple-block grid concept to the full extent by per- 
mitting an arbitrary number of structured grid blocks with user specifiable communication 
paths between blocks. The inter-block communication paths are implemented as a series 
of boundary conditions on each block which, in some cases, communicate flow informa- 
tion from one block to another. The advantages of the multiple-block solution concept are 
exploited throughout the remainder of this document as a means of treating complicated 
geometries, multiple blade row turbomachines of varying blade number, endwall treatments, 
and to exploit computational enhancements such as multigrid. 


2.2 Multiple Blade Row Solution Concepts 

Armed with an understanding of the multiple-block mesh solution concept discussed in the 
previous section, it is now possible to describe how this numerical solution technique can be 
applied to predict complicated flows. Specifically, this section deals with the prediction of 
flows through rotating machinery with multiple blade rows. Historically, the prediction of 
three-dimensional flows through multistage turbomachinery has been based on one of three 
solution schemes. These schemes are briefly illust rated and described in Figure 2.6. 
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ADPAC 2-D Nozzle Single Block Mesh Structure Illustration 


Physical Domain 



Computational Domain 



l 

Figure 2.1: ADPAC -07 2-D single block mesh structure illustration 
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ADPAC 2-D Nozzle Two Block Mesh Structure Illustration 


Physical Domain 



Computational Domain 



Figure 2.2: ADPAC07 2-D two block mesh structure illustration 
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ADPAC 2-D Nozzle Multiple Block Mesh Structure Illustration 

Physical Domain 



Computational Domain 



to couple computational domains 


IVirn' 2.:5: ADPAC07 2-1) multiple block mesh structure illustration 
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Figure 2.1: Coupled 0-H grid system for a turbine vane cascade 
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ADPAC 3-D O-H Turbine Grid Mesh Structure Illustration 

Computational Domain 


Block #2 

(Forward H-Grid) 


Block #3 

(Rearward H-Grid) 



Block to Block Communication Patches 


I Forward H-Grid 
Periodic Boundary 
M i MM i j Forward H-Grid 

0-Grid Connection 

O-Grid Periodic 
Boundary 


Rearward H-Grid 
Periodic Boundary 

Rearward H-Grid 
O-Grid Connection 




Rearward H-Grid 
O-Grid Connection 

O-grid cut 


□ Other boundaries (walls, 
inflow/outflow, etc. 


Figure 2.5: Computational domain communication scheme for turbine vane 0-H grid system 
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Multiple Blade Row Numerical Solution Concepts 

3-D Rotor/Stator Interaction Average-Passage Simulation Circumferential 

Mixing Plane 



3-D time-dependent Navier-Stokes 
equations 

Multiple blade passages for each 
blade row or phase-lagged boundaries 

Time-dependent coupling of individual 
blade passage domains 

Computationally expensive 
Multiple blade passages per blade row 


Average-passage equation system 

3-D steady solution of entire domain 
for each blade row 

Adjacent blade rows represented by 
blockage/body forces in 3-D solution 

Solutions have common axisymmetric 
flowfield 

Correlation model for mixing terms 


Steady Navier Stokes solution 

Computational domain limited to 
near blade region 

Circumferential mixing plane 
provides inter-blade row 
communication 

Lower computational cost 


Computational cost still rather high 


Figure 2.6: Multiple Blade Row Numerical Solution Schemes 





Multiple Blade Row Solution Concepts 1 1 

The first scheme involves predicting the time- resolved unsteady aerodynamics resulting 
from the interactions occurring between relatively rotating blade rows. Lx am pies of this 
type of calculation are given by Rao and Delaney [7], Jorgensen and ( luma [s], and Rai [12]. 
This approach requires either the simulation of multiple blade passages per blade row, or 
the incorporation of a phase-lagged boundary condition to account for the differences in 
spatial periodicity for blade rows with dissimilar blade counts. ( alculations of this type aie 
typically computationally expensive, and are presently impractical for machines with more 
than 2-3 blade rows. 

The second solution technique is based on the average- passage equation system devel- 
oped by Adamczyk [0]. In this approach, separate :I-D solution domains are defined for 
each blade row which encompasses the overall domain for the entire turbomachine. The 
individual solution domains are specific to a particular blade row. all hough all blade row 
domains share a common axisymmetric flow. In the solution for the flow through a spe- 
cific blade passage, adjacent blade rows are represented by their time and space-averaged 
blockage, body force, and energy source contributions to the overall flow. A correlation 
model is used to represent the time and space-averaged flow fluctuations representing the 
interactions between blade rows. The advantage of the average-passage approach is that 
the temporally and spatially averaged equations system reduce the solution toa st.eacl\ flow 
environment, and. within the accuracy of the correlation model, the solution is represen- 
tative of the average aerodynamic condition experienced by a given blade row under the 
influence of all other blade rows in the machine. The disadvantage of the average- passage 
approach is that the solution complexity and cost grow rapidly as the number of blade rows 
increases, and the accuracy of the correlat ion model is as yet unverified. 

The third approach for the prediction of flow through multistage turbomachinery is 
based on the mixing plane concept. A mixing plane is an arbitrarily imposed boundary 
inserted between adjacent blade rows across which the flow is “mixed out circumferen- 
tially. This circumferential mixing approximates the time-averaged condition at the mixing 
plane and allows the aerodynamic solution for each blade passage to be performed in a 
steady flow environment. The mixing plane concept was applied to realistic turbofan en- 
gine configurations by Dawes [10]. Flow variables on eit her side of the mixing plane are 
circumferentially averaged and passed to the neighboring blade row as a means of smearing 
out the circumferential nonuniformities resulting from dissimilar blade counts. The mixing 
plane concept is a much more cost-effective approach computationally because the flow is 
steady, and the individual blade passage domains are limited to a near-blade region. Un- 
fortunately. the accuracy of this approach is clearly questionable under some circumstances 
because of the placement of the mixing plane and the loss of spatial information resulting 
from the circumferential averaging operator. 

The A DPAC07 program possesses features which permit multiple blade row solutions us- 
ing either the time-dependent interaction approach or the mixing plane concept, described 
above. Average- passage simulations for realistic turbofan engine configurations were re- 
ported under Task IV of this contract, and further details on this approach can be found in 
Reference [11]. ADPAC07 predictions utilizing the time-accurate rotor/stator interaction 
technique requires that a sufficient number of blade passages be represented in each row 
such that the circumferential distance represented in each blade row is constant, this limits 
the blade counts which can be effectively simulated through this technique. For example, 
for the simple single-stage calculation suggested in Figure 2.0. if the rotor has :}(j blades and 
the stator has IN blades, a time dependent solution would require, as a minimum. 3 rotor 
blade passages and 1 stator blade passages to accommodate the common circumferential 
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pitch requirement. If the rotor has 35 blades, and the stator has 47 blades, however, then 
both blade rows would require that every blade passage be modeled as no simpler reduc- 
tion in blade count is possible. This restriction will appear quite often, as turbomachinery 
designers often do not like to design neighboring blade rows with blade counts which have a 
common integer factor. Ultimately, this type of problem will require the incorporation of a 
phase-lagged boundary condition which would permit time-dependent interaction solutions 
for neighboring blades using only one blade passage per blade row. 

If, instead, a mixing plane type of calculation is desired, then the multiple block scheme 
may again be invoked by utilizing a single blade passage per blade row, where each grid 
block has a common mating surface with a neighboring blade row. The only special re- 
quirement here is that boundary condition routines be available to adequately perform the 
circumferential averaging between blade rows and supply the block- to- block communication 
of this information in the multiple-block mesh solution algorithm. Section 3,7 describes the 
techniques for applying this type of boundary condition. 


2.3 Endwall Treatment Solution Concepts 

In this section, numerical techniques used to predict turbomachinery flowfields with endwall 
treatments are described. The general approach is to exploit the multiple block mesh capa- 
bilities of the ADPAC07 flow solver to couple endwall treatment and blade passage flowfields. 
Separate computational domains (mesh blocks) may be utilized for both the blade passage 
and at least one (or more) endwall treatment passages (grooves, slots, recessed vanes, etc.). 
Three specialized boundary conditions were developed to couple the indepedent flow do- 
mains. These boundary conditions result from various degrees of modeling assumptions 
used to simplify the blade passage/ treatment passage aerodynamic interaction. Each of the 
three boundary conditions and the assumptions inherent to each approach are described in 
detail below. 

For the prediction of compressor endwall treatment flows, separate numerical mesh sys- 
tems are utilized for both the compressor airfoil blade passages and the endwall treatment 
passages. The three different boundary condition procedures available to couple the end- 
wall treatment, /blade passage flowfields are illustrated graphically in Figure 2.7. The first 
technique, referred to as the direct-coupled approach, is utilized for those cases where there 
is a direct correspondence between mesh points in the treatment meshes and the blade 
passage meshes at the endwall interface. This construction permits a direct, point to point 
transfer of information from one mesh block to another. This approach is limited to geome- 
tries for which contiguous mesh systems can be generated, which, in general, is limited to 
circumferential groove casing treatments. 

The second approach, referred to as the endwall treatment time-average approach, 
is applied to endwall treatments which are non-axisymmetric in nature. This type of 
treatment includes discrete axial or blade angle slots, recessed vane sets, and circumfer- 
ential grooves. The primary objective of this approach was to develop a numerical cou- 
pling scheme for discrete treatments which would represent the time-averaged influence 
of the treatment passage/blade passage aerodynamic interaction. This approach is re- 
stricted to steady state flows due to the time-averaged assumption inherent in the pro- 
cedure, but simplifies the analysis in that only a single blade passage and a single dis- 
crete endwall treatment passage requires modeling in the overall solution. The endwall 
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Direct Coupled 
Boundary Procedure 



Passage View 



Meridional View 


Direct Point to 
Point Transfer 
of Information 

Between Treatment 

and Blade Passage 
Mesh Blocks 


Endwall Treatment 
Time- Average 
Boundary Procedure 



Meridional View 

Solution Applied Using a Single 
Treatment Passage Representation. 
Block to Block Data Transfer 

Based on Time-Averaged Flow 

and Weighted Linear Average 
Based on Intervening Endwall 
Segments 


Time— Accurate 
Boundary Procedure 



Passage View 



Meridional View 

Solution Applied to Multiple Blade/ 
Treatment Passage Representations. 
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Figure 2.7: Endwall treatment numerical boundary conditions 


treatment time-average boundary treatment is based on a concept similar to the mix- 
ing plane" (see e.g. [10]. [•!]) treatment described for multiple blade row flowfield pre- 
dictions. At the interface between the blade passage and the endwall treatment passage', 
flow data in each domain are circumferentially averaged (which represents a time average 
for a constant rotational speed, given the relative motion between the rotor and treat- 
ment passages), and passed to the neighboring domain as a boundary condition. 1 lie cir- 
cumferentially averaged data from the treatment passage is modified to account for the 
finite intervals of endwall separating adjacent treatment passages from the rotor point 
of view. The boundary conditions for the blade passage are then constructed as a lin- 
ear average of the circumferentially-averaged flow representation from the treatment grid 
and the known no-slip endwall boundary conditions. The linear average is based on the 
ratio of the circumferential extents of the treatment passage and intervening endwall. 
This scheme is illustrated graphically in Figure 2.7. Mathematically, for any variable d. 
the boundary condition for the blade passage at the treatment interface is computed as: 
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where c houndary is the boundary value applied for the blade passage, the SO terms are 
described on Figure 2.7, O represents a circumferential average of the data across the open 
area of the treatment, and Q no - s iip represents the appropriate no-slip boundary variables 
applied to the endwall portion of the overall treatment representation. 

The third coupling procedure is referred to as the time-accurate coupling procedure. 
This procedure is utilized for detailed time-dependent solutions of the endwall treatment /rotor 
aerodynamic interactions, and is utilized in much the same way as rotor/stator interactions 
are computed in multistage turbomachinery flowfields. This approach was limited to treat- 
ment geometries which were reducible to small integer numbers of treatments per blade 
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passage. This was done in order to minimize the circumferential extent of the rotor or 
treatment passages which must be modeled in order to employ a spatially periodic relation- 
ship for the overall blade passage/treatment representation. 


2.4 2-D/3-D Solution Zooming Concepts 

A fourth unique feature of the ADPAC07 solution system involves the concept of coupling 
two-dimensional and three-dimensional solution domains to obtain representative simula- 
tions of realistic high bypass ducted fan engine concepts. A complicating factor in the 
analysis of flows through turbofan engine systems results from the interactions between 
adjacent blade rows, and, in the case of a ducted fan. the effects of downstream blade rows 
on the aerodynamics of the upstream fan rotor. Historically, in the design of multistage 
turbomachinery, an axisymmetric representation of the flow through a given blade row has 
been used to effectively reduce the complexity of the overall problems to a manageable level. 
Similarly, an efficient approach to the numerical simulation of downstream blade rows could 
naturally utilize an axisymmetric representation of the effects of these rows through a two- 
dimensional grid system, with blade blockage, body force, and energy terms representing 
the axisymmetric averaged aerodynamic influence imparted bv the embedded blade row. 
This concept is illustrated graphically in Figure 2.8 for a representative turbine stage. 

A numerical solution of the flow through the fan rotor is complicated by the presence of 
the core stator, bypass stator, and bypass splitter. It is undesirable to restrict the solution 
domain to the fan rotor alone as this approach neglects the potential interactions between 
the fan rotor and the downstream geometry. The A DRACO 7 program permits coupled 
solutions of 3-D and 2-D mesh blocks with embedded blade row blockage, body force, 
and energy terms as a means of efficiently treating these more complicated configurations. 
Blade force terms may be determined from a separate 3-D solution, or may be directly 
specified based on simpler design system analyses. Neighboring 2-D and 3-D mesh blocks 
are numerically coupled through a circumferential averaging procedure which attempts to 
globally satisfy the conservation of mass, moment um and energy across the solution domain 
interface. The “dimensional zooming" capability permitted by the 2-D/3-D mesh coupling 
scheme is considered a vital asset for the accurate prediction of the flow through modern 
high-speed turbofan engine systems. 


2.5 Multigrid Convergence Acceleration Concepts 

for completeness, a brief section is included here to discuss the nmltigrid convergence accel- 
eration solution technique incorporated into the ADPAC07 code. Multigrid (please do not 
confuse this with a multiple- block grid!) is a numerical solution technique which attempts 
to accelerate the convergence of an iterative process (such as a steady flow prediction using 
a time-marching scheme) by computing corrections to the solution on coarser meshes and 
propagating these changes to the fine mesh through interpolation. This operation may be 
recursively applied to several coarsenings of the original mesh to effectively enhance the 
overall convergence. Coarse meshes are derived from the preceding finer mesh by eliminat- 
ing every other mesh line in each coordinate direction as shown in Figure 2.9. As a result, 
the number of multigrid levels (coarse mesh divisions) is cont rolled by the mesh size. and. in 
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2-D Axisymmetric Blade Row Representation 


3-D Geometry 2-D Axisymmetric Representation 



2-D Axisymmetric Representation 
of Stator Blade Row - Includes the 
Effects of Blockage, Body Forces and 
Energy Sources 


Figure 2.K: 2-1) axisymmetric flow representation of a turbomachinery blade row 
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the case of the ADPAC07 code, by the mesh indices of the boundary patches used to define 
the boundary conditions on a given mesh block (see Figure 2.9). These restrictions suggest 
that mesh blocks should be constructed such that the internal boundaries and overall size 
coincide with numbers which are compatible with the multigrid solution procedure (i.e., the 
mesh size should be 1 greater than any number which can be divided by 2 several times 
and remain whole numbers; e.g. 9, 17, 33, 65 etc.) Further details on the application of the 
ADPACQ7 multigrid scheme are given in Section 3.6 and in Reference [4]. 

A second multigrid concept which should be discussed is the so-called "fulF multigrid 
startup procedure. The "full" multigrid method is used to start up a solution by initiating 
the calculation on a coarse mesh, performing several time-marching iterations on that mesh 
(which, by the way could be multigrid iterations if successively coarser meshes are available), 
and then interpolating the solution at that point to the next finer mesh, and repeating 
the entire process until the finest mesh level is reached. The intent here is to generate 
a reasonably approximate solution on the coarser meshes before undergoing the expense 
of the fine mesh multigrid cycles using a "grid sequencing" technique. Again, the "full" 
multigrid technique only applies to starting up a solution, and therefore, it is not normally 
advisable to utilize this scheme when the solution is restarted from a previous solution as the 
information provided by the restart data will likely be lost in the coarse mesh initialization. 


2.6 General Solution Procedure Sequence 

The ADPAC07 code is distributed as a compressed tar file wdiich must be processed before 
the code may be utilized. The instructions in Appendix A describe how' to obtain the 
distribution file, and extract the necessary data to run the code. This operation is typically 
required only once when the initial distribution is received. Once the source files have been 
extracted, the sequence of tasks listed below 7 are typical of the events required to perform 
a successful analysis using the ADPAC07 code. 

Step 1.) Define the problem: 

This step normally involves selecting the geometry and flow 7 conditions, and defining 
which specific results are desired from the analysis. The definition of the problem must 
involve specifying whether steady state or time-dependent data are required, whether an 
inviscid calculation is sufficient, or whether a viscous flow 7 solution is required, and some 
idea of the relative merits of solution accuracy versus solution cost (CPU time) must be 
considered. 

Step 2.) Define the geometry and flow domain: 

Typically, geometric features such as airfoils, ducts, and flowpath end walls are required 
to geometrically define a given problem. The solution domain may be chosen to include 
the external flow , internal engine passage flow 7 s, and/or leakage flows. The flow domain is 
normally defined large enough such that the region of interest is far enough away from the 
external boundaries of the problem to ensure that the solution is not unduly influenced by 
the external boundary conditions. 

Step 3.) Define a block structure: 

Once the geometry and solution domain has been numerically defined, the implemen- 
tation of the solution mesh structure must be considered. This process begins with a 
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Multigrid Mesh Level Decomposition 


Fine Mesh Coarse Mesh Coarse Mesh 

(Level 1) (Level 2) (Level 3) 



Every other mesh line removed to define next mesh level 


Grid lines defining mesh boundaries (blade trailing edge, inlet/exit planes, etc.) 
must be consistent with the mesh coarsening process (cannot remove a mesh 
line defining a boundary in the coarsening process) 

Figure 2.9: Multigrid mesh coarsening strategy and mesh index relation 
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determination of the domain block structure, if and when more than one mesh block is 
required for a given solution. The possibility of incorporating 2- D mesh blocks should be 
considered whenever possible due to the computational savings afforded by this approach 
(see Section 2.3). 

Step 4.) Generate a numerical grid for the domain of interest: 

Most of the standard grid block structures defined in this document can be adequately 
handled through either the TIGGSD [18] or the G RIDGES [19] grid generation programs. 
Other grid generation programs may be equally useful, and a conversion program called 
MAKEADGRID (described in Chapter 7) is included to convert non-standard meshes into 
ADPACQ7 format. 

Step 5.) Generate a standard input file: 

The standard input file controls operations specific to a particular run of the AD - 
PAC'D! code. Options such as the number of iterations, damping parameters, and in- 
put/output control of the code execution may all be governed by the values specified in the 
standard input file. 

Step 6.) Generate a boundary data file: 

The boundary data file controls the application of boundary conditions on the grid 
block structure provided to the flow code. The boundary data specifications are specific to 
the mesh being used in a given calculation. For other block configurations, the user must 
construct the boundary data file by hand according to the format described in Section 3.7. 
A program is provided ( PA T( II FINDER ) in the ADPAC07 standard distribution to aid 
the user in locating contiguous block interface connections for multiple block meshes. 

Step 7.) Subdivide the problem for parallel execution: 

For execution across multiple processors, it may be necessary to subdivide the original 
block structure to permit the use of additional processors, or to aid in load balancing. The 
SIXPAC program is provided for this purpose. 

Step 7.) Define the computing environment: 

For parallel calculations, it is necessary to construct the procdef file which defines t he 
computing environment (machine name, number of processes, etc.). The relationship be- 
tween the number of processors and the number of mesh blocks should not be ignored, as it 
is up to the user to adequately balance the overall problem in a multiprocessor computing 
environment. 

Step 8.) Run ADPAC07 to predict the aerodynamics: 

Chapter 3 is available to describe the commands necessary to perform this task. A 
sample test case is also completely outlined in Appendix A. In many cases, a given calcu- 
lation will involve several applications of the ADPAC07 code, restarted from the previous 
calculation as a means of breaking up a large problem into several shorter calculations. 

Step 9.) Consolidate the block structure: 

For solutions which have utilized the block subdivision process ( SIXPAC , see above) it 
may be useful to consolidate the subdivided problem back into the original block structure. 
The BACPAC program is provided for this purpose. 

Step 10.) Plot and process the results: 



General Solution Procedure Sequence 


19 


An interactive post processing program called ADSP1N is provided to handle tasks such 
as mass-averaging flow variables to simplify the interpretation of the computed results (see 
Chapter 4). Output data is also provided for widely available plotting programs such as 
PLOTS I) [14] and FAST[Ui\. 

A condensed description of the commands involved in the steps described above begin- 
ning with extracting the source code from the distribution, compiling the codes, setting up 
a case, and running a case, is given in the Appendix. Separate sections are provided in the 
chapters which follow to describe in detail the basis and operation of the codes used in the 
steps above. 

It is worthwhile mentioning that the development and application of the codes described 
in this manual were performed on Unix-based computers. All files are stored in machine- 
independent format. Small files utilize standard ASCII format, while larger files, which 
benefit from some type of binary storage format, are based on the Scientific DataBase Li- 
brary (SDBLIB) format [14]. The SDBLIB format utilizes machine-dependent input/output 
routines which permit machine independence of the binary data file. The SDBLIB routines 
were developed at the NASA Lewis Research Center. 

Most of the plotting and graphical postprocessing of the solutions was performed on 
graphics workstations. The PLOTS 1) [11]. and FAST [16] graphics software packages de- 
veloped at NASA Ames Research ( enter were extensively used for this purpose, and data 
files for these plotting packages are generated automatically. These data files are written in 
what is known as PLOTS!) multiple-grid format . (See A DPACQ7 File Description. Section 
To). 


2.7 Consolidated Serial/Parallel Code Capability 

One of the practical difficulties of performing CFD analyses is finding sufficient computa- 
tional resources to allow for adequate modeling of complex geometries. Oftent imes, work- 
stations are not large enough, and supercomputers have either long queues, high costs, or 
both. Clearly, a means of circumventing these difficulties wit hout giving up the flexibility of 
the (TD code or the complexity of the model would be welcome. One possibility is to write 
a code which could run in parallel across a number of processors, with each one having only 
a piece of the problem. Then, a number of lesser machines could be harnessed toget her to 
make a virtual supercomputer. 

The most likely candidates for creating such a machine are the workstations which 
are fully loaded during the day. but sit idle at night. Tremendous power could be made 
available at no extra cost. There are also massively parallel computers available on the 
market designed specifically for such applications. These machines are aiming at order of 
magnitude improvements over present supercomputers. 

The problem, of course, lies in the software. Parallelization is today about as painful as 
vectorizat ion was a decade ago. There is no st andard parallel syntax, and no compiler exists 
which can automatically and effectively parallelize a code. It is difficult to write a parallel 
code which is platform independent. What makes things worse is that there is no clear 
leader in the parallel computer industry, as there has been in the supercomputer industry. 

The objective behind the development of the consolidated A DPA ( V 7 code described in 
this manual was to create a platform independent parallel code. The intent was to design a 
parallel code which looks and feels like a t raditional code, capable of running on networks of 
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workstations, on massively parallel computers, or on the traditional supercomputer. User 
effort was to be minimized by creating simple procedures to migrate a serial problem into 
the parallel environment and back again. 

2.8 Parallelization Strategy 

The ADPAC07 code has some innate advantages for parallelization: it is an explicit, multi- 
block solver with a very flexible implementation of the boundary conditions. This presents 
two viable options for parallelization: parallelize the internal solver (the "fine-grained'* 
approach), or parallelize only the boundary conditions (the "coarse-grained" approach). 
The fine-grained approach has the advantage that block size is not limited by processor size. 
This is the approach frequently taken when writing code for massively parallel computers, 
which are typically made up of many small processors. The coarse-grained approach is 
favored when writing code for clusters of workstations, or other machines with a few large 
processors. The dilemma is that a parallel ADPAC07 needs to run well on both kinds of 
machines. 

The fine grained approach is especially enticing for explicit solvers. Explicit codes have 
proven to be the easiest to parallelize because there is little data dependency between points. 
For a single block explicit solver, fine-grained parallelization is the clear choice. However, 
with a multiblock solver, the boundary conditions must be parallelized in addition to the 
interior point solver, and that can add a lot of programming effort. The coarse-grained 
approach is admittedly easier for multi-block solvers, but what if the blocks are too big for 
the processors? The simplest answer is to require the user to block out the problem so that 
it fits on the chosen machine. This satisfies the programmer, but the user is faced with a 
tedious chore. If the user decides to run on a different machine, then the job may have to 
be redone. The pain saved by the programmer is passed directly to the user. 

A compromise position was reached for parallel ADPAC07 code. The coarse-grained 
approach is used, but supplemental tools are provided to automatically generate new grid 
blocks and boundary conditions for a user-specified topography. In this way. the parallel 
portions of the code are isolated to a few routines within ADPAC07 . and the user is not 
unduly burdened with architecture considerations. Details of running AD PACQ7 in parallel 
are given in a later chapter. 
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ADPAC07 : 3-D 

EULER/NAVIER-STOKES 
FLOW SOLVER OPERATING 
INSTRUCTIONS 


3.1 Introduction to AD P AC 01 

This chapter contains the operating instructions for the ADPAC07 time-dependent multi- 
ple grid block :f-D Euler/Navier-Stokes aerodynamic analysis. These instructions include 
some general information covering executing the code, defining array limits, compiling the 
flow solver, setting up input files, running the code, and examining output data. The 
1 [) PA ('07 flow solver source programs are written in FORTRAN 77. and have been used 
successfully on Cray UN1C0S and IBM VM/CMS mainframe computer systems as well as 
IBM AIX Operating System and Silicon Graphics workstations using a I NIX operating 
system. 


3.2 General Information Concerning the Operation of the 
AD PACO 7 Code 

Approximate computational storage and CPU requirements for the ADPAC07 code can be 
conservatively estimated from the following formulas: 

CPU sec % 4.0.rl0 _5 (# grid points)(# iterations) 

Memory MW ss b.O.r l() -5 ( # grid points)=real number storage locations 
These formulas are valid for a Cray-C90 computer operating under the UNICOS environ- 
ment and the cf77 compiler, version 6.0. To. The times reported are for a single processor 
only, and are not indicative of any parallelization available through the Cray autot asking 
or microt asking facilities. The formulas are based on the standard, explicit solution algo- 
rithm using the algebraic turbulence model. Use of the implicit flow solver or higher order 
turbulence model could effectively increase both numbers by a factor of 1.4 or more. Use of 
parallel processing can substantially reduce these estimates on a per (11 basis. Without 
multigrid, steady inviscid flow calculations normally require approximately 2000 iterations 
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to reduce the maximum residual by three orders of magnitude ( 10 3 ) which is normally an 
acceptable level of convergence for most calculations. Viscous flow calculations generally 
require 3000 or more iterations to converge. When multigrid is used, the number of itera- 
tions required to obtain a converged solution is often one third to one fourth the number 
of iterations required for a non-multigrid calculation. Convergence for a viscous flow case 
is generally less well behaved than a corresponding inviscid flow calculation, and in many 
cases, it is not possible to reduce the maximum residual by three orders of magnitude due 
to oscillations resulting from vortex shedding, shear layers, etc. A determination of conver- 
gence for a viscous flow case must often be based on observing the mass flow rate, pressure 
ratio, or other global parameter, and terminating the calculation when these variables no 
longer change. The number of iterations required for an unsteady flow calculat ion is highly 
case-dependent, and may be based on mesh spacing, overall time-period, complexity of the 
flow, etc. 

The ADPAC'07 \>xogT&m produces output files suitable for plotting using the PLOTSD[ 14]. 
SURF [l o], and FAST [16] graphics soft ware packages developed at the NASA Ames Re- 
search ('enter. PLOTSD format data files are written for both absolute and relative flows 
(see Chapter 2 for a description of the PLOTSD format ). The user may also elect to have 
additional PLOTSD absolute flow data files output at constant, iteration intervals during 
the course of the solution. 1 hese files may be used as instantaneous flow ^snapshots'* of an 
unsteady flow prediction. 


3.3 Configuring ADPAC07 Maximum Array Dimensions 

The first, step required before attempting to compile and run the ADPAC'07 program is 
to set the maximum array size required for the analysis prior to the compilation process. 
The maximum array size will ultimately determine the largest problem (in terms of total 
number of mesh points) which can be run with the code. The larger the array limits, the 
larger the number of grid points which may be used. Unfortunately, setting larger array 
limits also increases the total amount of memory required by the program, and hence, can 
impede the execution of the code on memory-limited computing systems. Ideally, the code 
should be dimensioned just large enough to fit the problem at hand. It should be mentioned 
that storage requirements are dependent on whether the multigrid convergence acceleration 
technique is used or not. This dependency is explained in more detail in the paragraphs 
which follow. Approximate total computational storage and CPU requirements can be 
estimated for the ADPAC'07 aerodynamic analysis from the formulas listed in Section 3.2. 

Array dimensions are specified in the ADPAC'07 program by a set of FORTRAN PA- 
RAMETER statements. The array limits are specified in the source code file parame- 
ter. inc. A sample parameter. inc file is given below: 


parameter 

parameter 

parameter 

parameter 

parameter 

parameter 

parameter 


( nbmax 
( nra3d 
( nrald 
( nbl2d 
( nraint 
( nbcpbl 
( nbfra 


= 101 ) 
= 150000 ) 
= 3200 ) 

= 28000 ) 
= 1 ) 
= 7 ) 

= 65000 ) 
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parameter 

parameter 

parameter 

parameter 

parameter 

parameter 


( lgrafx = 1 ) 

( nsyst = 1 ) 

( nbffile = 16 ) 

( nbcntl = 100000 ) 

( nimpra =1 ) 

( n2eqra = 1 ) 


Karh statement in the parameter. inc file is ultimately embedded in every subroutine 
through a FORTRAN include statement . During execution, the . \Dl\ \( '07 program au- 
tomatically checks to make sure enough storage is available for all the blocks and issues a 
fatal error message il an array size is exceeded. 

Before proceeding with a description of the various parameter variables, il should be 
mentioned that a computational tool is available called ADS1A7 which will lead in an 
Al)PA('()1 ready mesh file and determine the required parameter sizes for either a multigrid 
or non-multigrid run. The ADS1A I program is described in more detail in ( haptei 10. 

The various PARAMETER variables utilized in the parameter. inc file are described 
below. 


NBMAX 

The parameter NBMAX defines the maximum number of grid blocks permitted during 

execution of the ADPAC07 multiple block solver. This number must be large enough to in- 
chub' every level of coarse mesh blocks created during a multigrid run. 1 he ADI A( 0 / code 
exploits the multiple block mesh structure during multigrid runs by creating and storing 
coarse mesh blocks from the corresponding fine mesh blocks. In other words, if it is intended 
to run a 5 block mesh with 3 levels of multigrid, then the parameter NBMAX must be at 
least 15. 

NRA3D 

The parameter NRA3D defines the maximum total number of computational cells permit- 
ted for the finite volume time-marching algorithm. This parameter essentially limits the 
maximum total number of mesh points (including multigrid coarse meshes, when applica- 
ble) which are permitted during an ADPAC07 run. The minimum value for the NRA3D 
parameter for a given mesh system may be calculated as follows: 

m=NBLKS 

XRAW > Y, [(lMX)m + l][Uil/A') m + l][(KMX) m + 1] 

7)1 = 1 

where Y),„. (JMX) m . and [KMX) m indicate the number of mesh points in the i. 
j, and k mesh coordinate directions, respectively, for mesh block m. and A HLhS is ihe 
total number of grid blocks. Sample calculations of the minimum value for the NRA3D 
parameter for a multiple block mesh are provided below. 

Suppose we intend to perform a solution on a mesh consisting of 3 mesh blocks with 
19.rl7.cl7. 2. r ).rl7.r 17. and r29.r33.r49 mesh points, respectively. Fora non-multigrid calcu- 
lation. t he total number of mesh blocks is simply 3. and the minimum value for parameter 
NRA3D may be computed as: 


Y DAM) = (49+ 1 )( 1 7 + 1 )( 17 + l) + (25+ 1 )( 1 < + 1 )( 1 7 + 1 ) 
+ (129+ 1 )( 33 + 1 )(49 + 1 ) = 245.624 
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If, using the same mesh system, it is desired to employ 3 levels of multigrid, additional 
storage must also be allocated for the coarse mesh systems, and the minimum value for 
parameter NRA3D must be recomputed as: 

(NRAliDh = (49 + 1 )( 17 + 1 )( 17 + l) + (25 + 1 )(17 + 1)( 17 + 1 ) 

+( 129 + 1 )(33 + 1 )(49 + 1 ) = 245. 624 

(NRAiDh = (25 + 1)(9 + 1)(9 + 1) + (13 + 1)<9 + 1)(9 + 1) 

+( 65 + 1 )( 17 + 1 )( 25 + 1 ) = 34. XXX 

(NRAliDh = (13 + 1 )(5 + 1)(5 + 1 ) + (7 + 1 )(5 + 1)(5 + 1) 

+(33 + 1 )(9 + 1 )( 13 + 1) = 5.552 

X RAID = (NRAWh + (NRAiDh + (NRA1D) :} = 286,064 

The requirement that the parameter variable NRA3D (and others) be based on array 
sizes 1 element larger than the grid dimensions results from the use of phantom points 
outside the computational domain to impose the numerical boundary conditions. 

NBL2D 

The parameter NBL2D is used to define the size of the temporary 2-D arrays utilized 

during the advancement of the time-marching algorithm for a given mesh block. As such, 
the parameter is based on the largest single dimension of any mesh block (2-D or 3-D) and 
may be determined by the following formula: 

N B LID > (rnax m=hNBLh - s [(IMX) m + 1 .(JMX) m + h(KMX) rn + l]) 2 

where the variables IM A\ J M A , K M X , N BLK S are defined in the section describing 
NR A 3D above. 

Returning to the example mesh system utilized in the description of the parameter 
NRA3D, the minimum value for the parameter NBL2D may be computed as: 

NBL'ID = ( 129 + 1 ) 2 = 16900 

This value is unchanged regardless of the number of multigrid levels since coarser meshes 
always result in smaller mesh sizes. 

NRA1D 

The parameter NRA1D is used to define the size of several 1-D arrays used to do various 

bookkeeping operations during the execution of the A DPACQ7 code. As such, the parameter 
is based on the sum of the maximum single dimension of all mesh blocks in the following 
manner: 


m-N BLK S 

N RAID > Y, nm.r{( IM X ) m + l.(JM X ),„ + 1 , ( A ‘ M X ) m + 1 ] 

771 = 1 

Returning to the example mesh system utilized in the description of the parameter NRA3D. 
the minimum value for the parameter NRAlD for a non-multigrid run be determined as: 


N RAID = (49 + 1 ) + ( 25 + 1 ) + ( 129 + 1 ) = 206 
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and for a 3 level multigrid run as: 

(NRAiD) 1 = (19 + 1) + (25 + 1 ) + ( 129 + 1 ) = 200 

( Y RA 1 1) h = (25 + 1 ) + ( 13 + 1 ) + (05 + 1 ) = 100 
(NRA\D) :i = (13+ l) + (7+ l) + (33+ 1 ) = 50 
N RAID = ( A RAID)\ + ( N RA l D ) 2 + ( N RA 1 D ) ;) = 308 


NBCPBL 

| | i (' parameter NBC P B L is used to defi lie the size ol the an a\ s u sed 1 o st oi e t he bounda i \ 
condition specifications for a given A D RAC‘07 run. Since the number of boundary conditions 
normally scales according to the number of mesh blocks (as a minimum. 0 boundary con- 
ditions are required for each 3-1) mesh block, see Section 3.<)- the parametei NBCPBL 
implies the maximum number of boundary conditions per block, and the overall num- 
ber of boundary conditions is determined by multiplying the parameters NBMAX and 
NBCPBL. It should be noted that a single block can. in fact, possess more than NBCPBL 
boundary condition specifications as long as the total number of boundary condition speci- 
fications for the entire problem does nol exceed A UMAX * A IK DHL. 

NRAINT 

The parameter NRAINT is used to define the size of the temporary arrays used to store 

interpolation data lor the noil-contiguous mesh patching boundary condition specification 
PINT, described in Section 3.7. The PINT specification controls the numerical coupling 
bet wen'll two mesh blocks possessing lion-contiguous mesh boundaries which lie on a com- 
mon surface. The numerical scheme utilizes a rather simple interpolation scheme based on 
an elect rical circuit analogy, and stores the "nearest neighbors" for each mesh point to avoid 
the expense of constantly searching for the interpolation stencil between the two mesh sur- 
face's. Determining the value required for the parameter NRAINT is normally performed 
by summing up all of the mesh elements involved in all of the PINT specifications (in- 
cluding coarse mesh specifications from a multigrid run). For example, if two meshes with 
noncontiguous mesh boundaries of 19x33 and 25x1 < are being updated using the PINT 
specification, then the minimum value for the NRAINT parameter for a nonmultigrid run 
would be determined as: 

NRAINT = (49- 1)(33- 1) + (25 - 1 )( 17 — 1)= 1920 

In this case, the NRAINT parameter is based on the mesh indices minus one. since the 
storage in the finite volume solver is actually based on the number of mesh cdls, not the 
number of mesh points, even though the boundary specification is based on actual nnsh 
indices. The equivalent value for a run utilizing 3 levels of multigrid would be: 

(NRAINTU = (49 - 1 )( 33 — 1 ) + (25 - 1 )( 17 - 1 ) = 1920 

(NRAINT)-i = (25- 1 )( 1 7 — 1) + (13- 1)0— D = 180 

(NRAINTh= (13- 1 )(9 — 1 ) + (7 — 1)(5- 1) = 120 

NRAINT = ( N RAI NT)\ + ( N RAI NT) 2 + (NRAINT)* = 2520 

Naturally, if additional PINT specifications are employed then the contributions from 
these specifications must also be added to the total. 
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NBFRA 

The parameter NBFRA is used to define t he size of the 2-D arrays used to store the blade 

element blockage, body force, and energy source terms for the 2-D block solution scheme. 
Since these arrays are utilized for any 2-D mesh block regardless of whether blade element 
blockage and source terms are utilized, the arrays must be dimensioned large enough to 
store all the elements of all of the 2-D mesh blocks (including coarse meshes for multigrid 
runs) much in the manner that NRA3D is used to store all of the elements of all of the 
mesh blocks. Mathematically, the minimum value for the parameter NBFRA may be 
calculated as: 

m=XBLK$ 

NBFRA > Y1 [OMX) m + l][(JMX) n + \}L 2D (m) 

m — 1 

where the variables IMA.JMA.KMA and NBLKS are described in the definition of 
parameter NRA3D. above. The variable is a trigger to indicate whether the grid 

block m is 2-D (1) or 3-D (0). For example, suppose a multiple block solution is being 
performed for a mesh system comprised of two 2-D meshes sized 49x25x1 and 33x17x1 and 
a 3-D mesh sized 33x25x29. For a non-multigrid run, the minimum value for the parameter 
NBFRA may be calculated as: 

NBFRA = (49+ 1)(25+ 1 )( 1 ) + (33 + 1 )( 17 + 1 )( 1 ) + ( 129 + 1)(25+ 1)(0) = 1912 
and for a run employing 3 levels of multigrid as: 

( N B FRA) i = (49+ 1)(25+ 1 )( 1 ) + (33+ 1 )( 17 + 1 )( 1 ) + ( 129 + 1)(25+ 1)(0) = 1912 

( N B F R A) 2 = (25+ 1 )( 13 + 1 )( 1 ) + ( 17 + 1)(9+ 1 )( 1 ) + (65 + 1 )( 13 + 1 )(0 ) = 544 
(NBFRAh = (13+ 1 )(7 + 1)( 1) + (9 + 1 )( 5 + 1 )( 1 ) + (33 + 1)(7+ 1)(0) = 172 
NBFRA = (NBFRAh + ( NBFRAh + (NBFRA). i = 2628 


LGRAFX 

The parameter LGRAFX is used to define the size of the temporary 3-D arrays used 

for the run-time graphics display option available in the A 1)PA C07 code. If the run-time 
graphics option is employed, then the parameter LGRAFX can be determined in the 
same manner as the parameter NRA3D. If the run-time graphics option is not employed, 
then the parameter LGRAFX should be set to 1. resulting in a considerable savings in 
computational storage. 

NSYST 

The parameter NSYST is used to define the size of a character array which stores system 

call commands during the execution of the boundary condition routine SYSTEM (see 
Section 3.7). Normally, this is not used and may be set to a value of 1 to minimize storage. 
If the SYSTEM boundary routine is used, then NSYST must be at least as large as the 
number of SYSTEM boundary specifications in the ADPAC07 boundary data file. 

NBFFILE 

The parameter NBFFILE is used to define the size of a character array which stores body- 
force file names specified by the input variable BFFILE (see Section 3.0). Normally, this is 
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not used and may he set to a value of 1 to minimize storage. If the BFFILE input variable 
is used, then NBFFILE must he at least as large as NBMAX. 


NBCNT1 

The parameter NBFFILE is used to define the size of the arrays used to save the interpo- 
lation stencils used in the BCINT1 and BCINTM non-aligned mesh boundary coupling 
schemes. In an effort to increase computational and communication efficiency, the inter- 
polation stencils used to update the non-aligned boundaries in these boundary condition 
routines are only calculated on the first step, and are subsequently saved to eliminate any 
redundant calculation. The NBCNT1 parameter must be at least as large as the sum 
of the total number of points along all BCINT1 and BCINTM non-aligned boundary 
patches. If BCNT1 is set to 1, then the interpolation stencil saving feature is disabled, 
and the interpolation stencil is recalculated at every time step. 

NIMPRA 

The parameter NIMPRA is used to define the size of the arrays used in t he .■ 1 DPA C07 im- 
plicit solution algorithm. For time-dependent solutions involving the iterative implicit so- 
lution algorithm, up to two additional time levels of the conserved flow variables must be 
stored, and this storage is defined based on the value of (NIMPRAxNRA3D+ 1 ). I he 
value of NIMPRA should therefore be either 0 (no implicit time level storage) or 1 (pro- 
vide implicit time level storage). If an implicit solution is attempted when the code has 
been compiled with NIMPRA=(). an error will result . 

N2EQRA 

The parameter N2EQRA is used to define the size of the arrays used in the ADPAC07 two- 

equation turbulence model solution algorithm. For solutions involving the two-equation 
t urbulence model, additional storage is required for the dependent variables and numerical 
fluxes employed in the solution of the turbulence transport equations, and this storage is 
defined based on the value of (N2EQRAxNRA3D + l ). The value of N2EQRA should 
therefore be either 0 (no two-equation turbulence model storage) or 1 (provide two-equation 
turbulence model storage). If a two-equation turbulence model solution is attempted when 
the code has been compiled with N2EQRA=0. an error will result. 

3.4 ADPAC07 Compilation Using Makefile 

Compilation of the A DPAC07 source code into an executable form is handled through a 
UNIX-based Makefile facility. A Makefile is included with the standard distribution which 
permits automatic compilation of the code for several operational capabilities (both serial 
and parallel) and computer systems. The format of the Makefile compiling command is 
described below. 

Several items should be mentioned prior to detailed discussion on the actual Makcfih 
utilities. Section 3.5 describes the format of the binary files using the Scientific Database 
Library developed at NASA- Lewis [13]. The original version of the Scientific Database 
Library was found to be rather slow on some machines, and an equivalent limited capability 
(.’-based library was developed to accelerate the I/O processing in the code. This library 
is referred to as ('SI)IL and separate options for utilizing the C’SDH library are included 
in the Makefile. In addition, the consolidated code is capable of both serial and parallel 
operation depending on the Makefile operation selected. 
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In the directory containing the FORTRAN source of the ADPACO 7 code, compilation 
is performed by executing the command: 

make option 

The make command is standard on UNIX systems and automatically interrogates the 
file Makefile for instructions on how to perform the compilation. The option argument may 
be any of the variables listed below: 

Standard UNIX (Silicon Graphics) Make Options 

(No argument) This is the standard UNIX system compilation for the 
serial version of the ADPAC07 code. All non-standard programming 
constructs are avoided (such as graphics, or multi processor features). 
This option will deliver a working executable on most UNIX systems 
w hich support standard naming conventions (/77as t he standard com- 
piler. etc.). The compilation includes basic compiler optimization (f77 
-0). The executable name is adpac. 

csdb This is the same as link above, except that the faster ( '-based scientific 
database library is linked instead of the standard scientific database 
library. Prior to performing this compilation, the appropriate make 
command must be issued in the CSDB directory to assemble the CSDB 
library for the local machine. The executable name is adpac. 
pfa This option is used on Silicon Graphics computers supporting the 
Power FORTRAN compiler option. Power FORTRAN is a Silicon 
Graphics product which does automatic multiprocessor compilation 
and is therefore not related to the ADPAC'07 message-passing paral- 
lelization strategy. The pfa compiled code is therefore still operated 
as a serial code, although it may execute on multiple processors for 
Silicon Graphics workstations. The number of processors used is set 
by the NUM-THREADS environment variable. The compilation in- 
cludes basic compiler optimization (f77 -()). The executable name is 
adpac_pfa. 

csdb -pfa This option is the same as pfa above, except that the faster (’-based 
scientific database library is linked instead of the standard scientific 
database library. Prior to performing this compilation, the appropri- 
ate make command must be issued in the CSDB directory to assemble 
the CSDB library for the local machine. The executable name is ad- 
pac_pfa. 

graphics This option compiles ADPAC07 with the necessary routines needed to 
permit interactive graphics between network connected Silicon Graph- 
ics workstations. This option will only w T ork when compiling on a Sili- 
con Graphics workstation with IRIX operating system 4.0.1 or above. 
The full Silicon Graphics shared graphics libraries and X-windows sys- 
tem graphics libraries must be installed on the compiling workstation 
in order for this option to work. This feature is not recommended as 
it generally decreases performance and other visualization techniques 
are likely to produce more desirable results. The executable name is 
adpac .graphics. 
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csdb.grapliie* This option is the same as graphic* above, except that t he faster <•- 
based scientific database library is linked instead of the standard sci- 
entific database library. Prior to performing this compilation, the ap- 
propriate make command must be issued in the ( 'SDH directory to 
assemble the CSDB library for the local machine. The executable 
name is adpac_graphics. 

dbx This option is used for generating an executable version of the serial 
code which is compatible with the standard UNIX r//w- based debug- 
ging facility. This should work on any standard UNIX machine which 
supports (lb.r (Note: the code will run much more slowly when com- 
piled in this fashion.) This option is used mainly for code development 
or debugging. The executable name is adpac_dbx. 
csdb-dbx This option is used for generating an executable version of the serial 
code which is compatible with the standard UNIX dbx - based debugging 
facility using the CSDB library. This should work on any standard 
UNIX machine which supports dbx (Note: the code will run much more 
slowly when compiled in this fashion.) This option is used mainly for 
code development, or debugging. The executable name is adpac_dbx. 
dbx.gmpliirs This option is used for generating an executable version of the se- 
rial code with run-time graphics enabled which is compatible with the 
standard UNIX r//w- based debugging facility using the CSDB library. 
This should work on any standard UNIX machine which supports dbx 
(Note: the code will run much more slowly when compiled in this fash- 
ion.) This option is used mainly for code development, or debugging. 
The executable name is adpac_dbx_graphics. 
parallel This is the standard UNIX system compilation for the parallel version 
of the ADPAC07 code. The standard A PUL message passing library 
is incorporated, and therefore creation of this executable requires that 
a makf has been issued in the Al’PL directory on the current machine. 
The parol If I code may only be executed using the APPL compute func- 
tion with a corresponding APPL proedef file. Prior to performing this 
compilation, the appropriate make command must be issued in the 
APPL directory to assemble the APPL library for the local machine. 
The executable name is adpaep. 

paralkLcsdb This is the same as parallel above, except that the faster ('-based 
scientific database library is linked instead of the standard scientific 
database library. Prior to performing this compilation, the appropriate 
makf command must be issued in the CSDB and APPI. directories to 
assemble the CSDB and APPL libraries for the local machine. The 
executable name is adpaep. 

pa ml If IJbx This is the same as parallel above, except t hat specific compiler opt ions 
have been enabled to utilize the UNIX dbx debugging facility. Prior 
to performing this compilation, the appropriate make command must 
be issued in the SDBLIB and APPL directories to assemble the SDB 
and APPL libraries for the local machine. This should work on any 
standard UNIX machine which support s dbx ( Note: the code will run 
much more slowly when compiled in this fashion.) This option is used 
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mainly for code development or debugging. The executable name is 

adpacp. 

parallcLcsdbJLbx This is the same as paralleLcselb.dbx above, except that the faster 
C- based scientific database library is linked instead of the standard 
scientific database library. Prior to performing this compilation, the 
appropriate make command must be issued in the CSDB and APPL 
directories to assemble the CSDB and APPL libraries for the local 
machine. This should work on any standard UNIX machine which 
support s elbx ( Note: the code will run much more slowly when compiled 
in this fashion.) This option is used mainly for code development or 
debugging. The executable name is adpacp.dbx. 

paralleLpvm This is the standard UNIX system compilation for the parallel ver- 
sion of the ADPAC07 code using the PVM message passing library. 
The standard APPL message passing library is incorporated as a sub- 
layer between the native PVM calls and the ADPAC07 programming 
message- passing calls, and therefore creation of this executable requires 
that a make has been issued in the APPL directory on the current 
machine. The parallel code may only be executed using the APPL 
compute function with a corresponding APPL procdef file. Prior to 
performing this compilation, the appropriate make command must be 
issued in the APPL directory to assemble the APPL library for the 
local machine. The executable name is adpacp.pvm. 

Silicon Graphics Power Challenge Make Options 

pence r.challe neje This option is utilized when compiling the standard serial code on 
a, Silicon Graphics R8000 (Power Challenge @) computer. For best 
performance, several machine specific optimizations are enabled. The 
executable name is adpac_power .challenge. 

Cray (UNICOS) Make Options 

cray This option is utilized when compiling the standard code on a Cray 
computer (implies a serial code). For best performance, the aggressive 
optimization option of the Cray compiler has been invoked (cf77 Zv 
-\\ f Wk -o aggress”). The executable name is adpac_cray. 

cray.dbx This option is used for generating an executable version of the code 
which is compatible with the Cray cdbx debugging facility. (Note: 
the code will run much more slowly when compiled in this fashion.) 
This option is used mainly for code development or debugging. The 
executable name is adpac_cray_dbx. 

nCUBE2 Vertex Operating System Make Options 

ncube This is the standard nCUBE 2 system compilation for the parallel 
version of the ADPAC07 code. The nCl BE version of the APPL 
message passing library is incorporated, and therefore creation of this 
executable requires that a make has been issued in the APPL directory 
on the current machine. The parallel code may only be executed using 
the APPL compute function with a corresponding APPL procdef file. 
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ncubf-csdb 


ncvbc -db.r 


■ncubf -csdb-dbf 


nculx „csdb-no2d 


air 


aix-csdh 


aiv-dbx 


au'-Csdb-dbx 


Prior to performing this compilation, the appropriate maki command 
must be issued in the APPL directory to assemble the A PPL library 
for the local machine. The executable name is adpacp_ncube. 

This option is identical to nculx above, except that the faster ('-based 
scientific database library is linked instead of the standard scientific 
database library. Prior to performing this compilation, t he appropriate 
utakt command must be issued iu the CSDB and APPL directories to 
assemble 1 he ('SDH and APPL libraries for the local machine. The 
executable name is adpacp_ncube. 

This option is used when compiling the parallel code for the nCUIIL 
parallel computer using the VERTEX operating system and t he nCEBE 
dbx debugging facility. (Note: the code will run much more slowly when 
compiled in this fashion.) This option is used mainly for code devel- 
opment or debugging. The executable name is adpacp_ncube_dbx. 

This option is the same as nculx. db.r above, except that the faster ('- 
based scientific database library is used instead of the standard scien- 
tific database library. (Note: the code will run much more slowly when 
compiled in this fashion.) The executable name is adpacp_ncube_dbx. 

This option is used when compiling the parallel code for the nCEBE 
parallel computer using the VERTEX operating system and the faster 
(‘-based scientific database library instead of the standard scientific 
database library. This option also eliminates all 2-D subroutines to 
minimize the size of the executable, which is useful for strictly 3-D 
problems on multiprocessing computers with limited memory per pro- 
cessor. Prior to performing this compilation, the appropriate mah 
command must be issued in the ('Sl)B and APPL directories to as- 
semble the CSDB and APPL libraries for the local machine. The 
executable name is adpacp_ncube_no2d. 

IBM RS-6000 AIX Make Options 

This option is used when compiling the standard serial code on an 
IBM RS-0000 workstation running the AIX operating system. The 
executable name is adpac_aix. 

This option is identical to air above, except that the faster (’-based 
scientific database library is linked instead of the standard scientific 
database library. Prior to performing this compilation, the appropri- 
ate makf command must be issued in the CSDB directory to assemble 
the CSDB library for the local machine. The executable name is ad- 
pac_aix. 

This option is used for generating an executable version of the code 
which is compatible with the IBM AIX dbx debugging facility. (Note: 
the code will run much more slowly when compiled in this fashion.) 
This option is used mainly for code development or debugging. The 
executable name is adpac_aix_dbx. 

This option is identical to aix.dbx above, except that t he faster ( ' based 
scientific database library is linked instead of the standard scientific 
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database library. Prior to performing this compilation, the appropriate 
make command must be issued in the CSDB directory to assemble 
the CSDB library for the local machine. (Note: the code will run 
much more slowly when compiled in this fashion.) This option is used 
mainly for code development or debugging. The executable name is 
ad pac _aix _d bx . 

eiix ..parallel This is the standard IBM RS-6000 AIX UNIX system compilation 
for the parallel version of the ADPAC07 code. The standard APPL 
message passing library is incorporated, and therefore creation of this 
executable requires that a make has been issued in the APPL directory 
on the current machine. The parallel code may only be executed using 
the APPL compute function with a corresponding APPL procdef file. 
Prior to performing this compilation, the appropriate make command 
must be issued in the APPL directory to assemble the APPL library 
for the local machine. The executable name is adpacp_aix. 

(lix-peimlleLcsdb This option is identical to aix.parallel above, except that the faster 
(Abased scientific database library is linked instead of the standard 
scientific database library. Prior to performing this compilation, the 
appropriate make command must be issued in the CSDB directory 
to assemble the CSDB library for the local machine. The executable 
name is adpacp_aix. 

(lix-pcimlleLclbx This option is used for generating an executable parallel version of 
the code which is compatible with the IBM AIX dbx debugging facil- 
ity. (Note: the code will run much more slowly when compiled in this 
fashion.) This option is used mainly for code development or debug- 
ging. The executable name is adpacp_aix_dbx. 

NASA-Lewis Research Center Specific Make Options 


lace This option is used when compiling the standard parallel code for the 
NASA-Lewis LACE workstation cluster computing environment. The 
executable name is adpacp_lace. 

letce _csdb This option is identical to lace above, except that the faster ('-based 
scientific database library is linked instead of the standard scientific 
database library. Prior to performing this compilation, the appropri- 
ate make command must be issued in the CSDB directory to assemble 
the CSDB library for the local machine. The executable name is ad- 
pacp_lace. 


leather This option is used when compiling the standard parallel code for 
the NASA-Lewis SP2 (leather) workstation cluster computing envi- 
ronment. The executable name is adpacp.leather. 

leathe r-csdb This option is identical to leather above, except that the faster (’--based 
scientific database library is linked instead of the standard scientific 
database library. Prior to performing this compilation, the appropri- 
ate make command must be issued in the CSDB directory to assemble 
the CSDB library for the local machine. The executable name is ad- 
pacpJeather. 
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Source Directory Maintainance Make Options 

help This option list s and describes all available make file options. No exe- 
cutable is created. 

clean This option cleans up the source directory by removing all object files. 
No executable is created. 

realelean This option really cleans up the source directory by removing all object 
and library files. No executable is created. 

o n ( so u rce This option concatenates all the ADPAC01 source files into a single 
source file name adpuc.one source .j. I his single source can then be 
compiled by hand on those machines for which an appropriate meike 
option is not available. It is up to the user to link in the necessary 
library files (('SDH, APPL. etc) for creation of an executable. No 
executable is created. 

At t lie completion of the compilation process on any system, an executable version of the 
code is written in the source directory (see Appendix A for an application of the compilation 
and execution processes for a sample test case). 

3.5 ADPACO 7 Input /Output Files 

In this section, the various input/output data files related to a calculation using the AD- 
PA ('07 program are described. In order to understand the file naming convention, the 
concept of a case name must firsl be detailed. All files used in an A1)PA( 01 calculation 
are named according to a standard naming convention of the form: 

cast . exte nsion 

where ease is a unique, user-specifiable name identifying the geometry or flow condition 
being investigated, and extension is a name describing the type of file. The ease name must 
be specified in the standard input file described below. A list and description of each of the 
files used or generated by ADPAC 07 is given in fable .1.1. 

The standard input, standard output, boundary data, and convergence history files are 
stored in ASCII format. All other files utilize the Scientific DataBase Library (SDBLIB) [13] 
format. The mesh file and PLOT. ID plot output files are compatible with the PLOT ID 
multiple grid, binary definition (see Sections 3.S and 3.11 for a description and coding 
examples of the SDBLIB binary format). Files dealing with the parallel execution of the 
ADPAC07 code are described in Chapter 1. 

The standard input and standard out put files are directed at runtime using the st andard 
I N1X redirection syntax as: 

adpac < case. input > case. output 

If a restart run is desired, the user must move the most current output restart file from 


rase , restart .new 
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Table 3.1: Description of input/output files and UNIX-based filenames for AD- 

PAC'D 7 Euler/ Navier-Stokes solver 


N ame 


Description 


rose .input 
rase, boundat a 
case, output 
case. mesh 
case .p3dabs 
ca.se. p3drel 
cast .p3d‘2eq 
ca.se. bf.# 
ca.se.p3fr.# 

ca.se.img.^ 

ca.se. rest art. new 
case . restart .old 
cast. 2eq rest, new 
ease. 2eq rest, old 
case .converge 
case .sixpac 
AVa.se .bacpac 
AVa.se. blkproc 
proedef 
case .axi.mesh 

ca.se.axi .restart .new 


Standard input file 

Block boundary definition file 

Standard output file (from output redirection only) 

Mesh file ( PL OTSD compatible) 

Final PL0T3D output file (absolute flow) 

Final PLOT 3D output file (relative flow) 

Final PL0T3D output file (turbulence model data) 

2-D blockage/ body force file for block number # 

Instantaneous PLOT 3D interval output file 
(absolute flow). The frame number is given by #. 

Instantaneous Silicon Graphics image file for graphics 
interactive display. The frame number is given by #. 

New restart file (output by code) 

Old restart file (used as input for restart runs) 

New turbulence model restart file (output by code) 

Old turbulence model restart file (used as input for restart runs) 
Solution residual convergence history file 
SIXPAC block subdivision file (parallel only) 

BA CPA C block reconstruction file (parallel only) 

ADPAC07 block /processor assignment file (parallel only) 

APPL process description file (parallel only) 

Equivalent axisymmetric mesh output bv body 
force calculation 

Equivalent axisymmetric flow restart output by 
bodv force calculation 
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to the default, input restart file name 


ease . restart .old 

each time the code is restarted. A more detailed description of the use and format of the 
ADPAC07 files is presented in the sections which follow. 

3.6 A D PA CO 7 Standard Input File Description 

The standard ADPAC07 input file case. input contains the user-specifiable parameters 
which control the basic operation of the code during execution. These parameters tend 
to be less case dependent (as opposed to the boundary data file which is entirely case de- 
pendent). During code execution, the input file is read one line at a time as a character 
string, and each string is parsed sequentially to determine the specific program action in 
each case. The standard input file utilizes a keyword input format, such that any line which 
does not contain a recognizable keyword is treated as a comment line. Therefore, the user 
may place any number of comments in the file (so long as the line does not contain a key- 
word input string in the form described below), and code execution is unaltered. Comments 
may also be placed after the variable assigned to the keyword as long as t here are one or 
more blanks separating the keyword value from the comment string. All inpul file lines 
are echoed to the standard output, and the program response to each line is listed when a 
specific action is taken. 

All keyword input lines are given in the following format: 

KEYWORD = Value Comment String 

where KEYWORD is one of the recognized keywords described below, and Value is the 
specific value to be assigned to that variable. The input line must contain t he equals sign 
( = ) with one or more blanks on both sides in order to be recognized. The Comment 
String must be separated by one or more blank spaces from the Value. Therefore, the lines 

DIAM = 10.000 

DIAM = 10.000 

DIAM = 10.000 This is the diameter. 

are valid kevword input lines assigning the value 10.0 to the variable associated with the 
keyword DIAM. Conversely, the lines 

DIAM= 10.000 
DIAM =10.000 
DIAM=10 . 000 

are not recognizable keyword input lines (in spite of the presence of the keyword DIAM), 
because' of the lack of proper placement of the blanks about the equals ( = ) sign. The 
purpose for this restriction is to permit keyword variables in comment lines, and to help 
users to generate readable input files. All keyword values are either real numbers (which, 
in many cases, are converted to integers in the code) or character strings. 

A sample A DPAC07 standard input file containing a number of typical use keywords is 
listed below: 
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A DPAC07 Sample Standard Input File 


ADPAC Input File 


NASA 1.15 

PRESSURE RATIO FAN 

- 2 BLADE ROWS 

VARNAME = 

= VARIABLE VALUE 

COMMENT 

CASENAME 

= 

nasa 

The case name is "nasa" 

FMULTI 

= 

3.0 

Three mesh levels for multigrid 

FSUBIT 

= 

1.0 

1 subiteration on each coarse mesh level 

FFULMG 

= 

1.0 

Use “full" multigrid 

FC0AG1 

= 

3.0 

Start "full" multigrid on 3rd mesh level 

FC0AG2 

= 

2.0 

End ’’full" multigrid on 2nd mesh level 

FITFMG 

= 

150.0 

150 "full" multigrid iterations 

RMACH 

= 

0.750000 

Reference Mach Number for initialization 

FINVVI 

= 

0.000000 

0.0-Inviscid Flow, 1.0-viscous flow 

GAMMA 

= 

1.400000 

Specific heat ratio 

PREF 

= 

2116.220000 

Reference Total Pressure (lbf /f t**2) 

TREF 

= 

518.670000 

Reference Total Temperature (Deg. R) 

RGAS 

= 

1716.260010 

Gas constant (f t-lbf /slug-deg R) 

DIAM 

= 

9 . 000000 

Reference diameter (ft.) 

EPSX 

= 

1 . 000000 

Residual smoothing coefficient in i direction 

EPSY 

= 

1.000000 

Residual smoothing coefficient in j direction 

EPSZ 

= 

1.000000 

Residual smoothing coefficient in k direction 

VIS2 

= 

0.500000 

Fine mesh 2nd order dissipation coefficient 

VIS4 

= 

0.015625 

Fine mesh 4th order dissipation coefficient 

VISCG2 

= 

0.125000 

Coarse mesh dissipation coefficient 

CFL 

= 

-5.000000 

<0.0, Steady flow, >0.0, unsteady flow 

FNCMAX 

= 

150.000000 

150 iterations on fine mesh level 

PRNO 

= 

0.700000 

Gas Prandtl number = 0.7 

PRTNO 

= 

0.900000 

Turbulent Prandtl number =0.9 

FREST 

= 

0.000000 

No restart file is read in 

ADVR(l) 

= 

-2.780000 

Advance ratio for block #1 is -2.78 

ADVR(2) 

= 

-2.780000 

Advance ratio for block #2 is -2.78 

ADVR(3) 

= 

0.000000 

Advance ratio for block #3 is 0.00 

ADVR(4) 

= 

0.000000 

Advance ratio for block #4 is 0.00 


ENDINPUT 

It is unnecessary to specify all possible keywords in every input file. The ADPAC07 code 
is programmed with a default set of input variables such that the only input variable 
which must be present is the CASENAME (described below) which is used to assign 
input/output file names. A list and description of all input keywords and their default 
values are listed below. 


A DPAC07 Standard Input File Keyword Description 
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ADVIl(NUM) 

(Default Value = 0.0) 

ADVR(l) = 0.0 
ADVR(2) =0.0 
ADVR(3) =0.0 

The ADVR keyword value determines the rotational speed (in terms of an advance ratio) of 
the mesh block number specified by the value A / M. Block rotational speeds are. by default, 
zero, unless either an RPM or an ADVR keyword are specified otherwise. The advance 
ratio is inherently tied to the freest ream Mach number specified in the value associated 
with the keyword RMACH. If the mesh has not been correctly non-dimensionalized. or if 
the value of RMACH is incorrect, it is possible that an incorrect value of rolational speed 
would be specified in the calculation. The use of ADVR is normally only employed lor 
propeller performance calculations. 

BFFILE(A7'.l/) 

(Default Value = default .file.name) 

BFFILE(l) = case.bf.bl 

The BFFILE keyword value determines the name of the file used to read in the data for 
the blade blockage and body force source terms used to represent t he effect s of embedded 
blade rows in 2-1) axisymmetric flow calculations. The file specified by BFFILE is used to 
describe the terms for the block number indicated by the value of .MM. Body force data 
files created by the A DP A ('01 program are named according to the file naming convention 
described in Section 3.9. 

CASENAME 

(No Default Value) 

CASENAME = case 

The CASENAME keyword value is used to set the case name which is used to define all 
input/output file names during an ADPAC07 run (see Section 3.5 for details). The case 
name is limited to an N character string, and cannot contain embedded blanks. The case 
name has no default value, and as such, all input files must contain the CASENAME 
keyword . 

CFL 

(Default Value = -5.0) 

CFL = -5.0 

The CFL keyword defines the value of the time step multiplier used in the time-marching 
solver. The algorithm is sensitive to the sign of the value used for CFL in determining the 
manner in which the time-marching solver is applied. If CFL < 0.0. local time stepping 
is used (steady flow only) and each cell is advanced in time according to the local maxi- 
mum allowable time step. If CFL > 0.0. then a time-accurate time-marching solution is 
performed using the explicit algorithm where the time step is based on the value of | CFL 
| x (A /)„„■„ where (A /),„,,, is the minimum of all local time steps. The absolute value of 
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CFL is used as a multiplier for the time step (larger absolute values indicate larger time 
steps). A value of -5.0 is normally used for steady flow calculations, and values as high as 

7.0 have been used successfully for time-accurate calculations. The value of CFL is also 
used implicitly in the eigenvalue scaling terms in the implicit residual smoothing algorithm, 
such that larger values of CFL imply increased residual smoothing (see the description 
of the implicit residual smoothing algorithm in the companion Final Report [21] and the 
description of CFMAX). For implicit calculations, the global time step is set by the input 
keyword FDELTAT. In this case, the value of CFL now controls the "pseudo" time step 
used during the inner iteration strategy at each global time step. In this case, each global 
time step can be viewed as a steady state solution, and the variables CFL, CFMAX, 
FMULTI, etc retain their meanings in this context, and should be set as in any steady 
state solution. The implicit time-dependent solution (and global time-dependent iteration 
strategy) is controled by the variables FIMPLIC, FDELTAT, FNTSTEP, FMGT- 
STEP, FIMPFAC, FTIMFAC. 

CFMAX 

(Default Value = 2.5 (four stage scheme). 3.5 (five stage scheme)) 

CFMAX =2.5 

The CFMAX variable is used to define the maximum allowable time step multiplier for 
the explicit time-marching scheme without residual smoothing. This value is used in the 
implicit residual smoothing routine to adjust the smoothing coefficients for variations in 
time steps (see the Filial Report [4]). Normally referred to as a CFL number, the variable 
CFMAX represents the maximum allowable CFL number for the time-inarching scheme 
without residual smoothing, while the variable CFL represents the actual CFL number 
used in the calculation with residual smoothing. The ratio of CFL to CFMAX is used to 
adjust the amount of smoothing in the residual smoothing operator. Increasing CFMAX 
decreases the magnitude of the residual smoothing coefficients and therefore decreases the 
overall smoothing. Based on linear stability analysis, the four stage Runge-Kutta time- 
marching scheme permits a maximum CFL number of 'ls/2. For simplicity, this value is 
normally approximated as 2.5 which provides an additional margin of safety. Under cert ain 
circumstances, it may be desirable to reduce CFMAX as low as 2.0 to aid convergence by 
artificially increasing the amount of residual smoothing. For the five stage scheme values of 

3.0 to 3.5 are recommended. 

CMUTSS. CMUTPS 

(Default Value = 14,0) 

CMUTSS =14.0 
CMUTPS =14.0 

The CMUTSS, CMUTPS keywords determine the ratio of local turbulent to laminar 
viscosity required to initiate transition for the point transition model in the ADPAC01 body 
centered mesh algebraic turbulence model activated by the keyword FTURBCHT. This 
simplified transition model maintains laminar flow until the ratio of near wall turbulent 
viscosity to near wall laminar viscosity exceeds the value of CMUTSS or CMUTPS 
for the "suction side" and "p ressure side", respectively, of the airfoil in question. The 
transition model parameters are illustrated in Figure 3.1. A ratio of 14.0 is recommended 
for all cases unless specific testing has indicated an alternate value. It should be noted that 
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those variables will have no effect when FIN WI— 0.0 (invisckl flow), or when F2EQ— 1.0 
(two- equation turbulence model enabled) or when FTURBCHT=0.0 (transition model 
not activated). 

DIAM 

(I)efault Value = 1.0) 

DIAM =1.0 

The DIAM keyword is used as a dimensionalizing length scale for the mesh system for a 
given case. The ADPAC07 code assumes that the mesh has been generated in a noudi- 
mensional fashion, and must be dimensionalized before execution. I he \alue of the DIAM^ 
variable is used to convert the supposed nondimensional mesh coordinates into a dimen- 
sional length scale with units of feet. In other words, if the mesh has been generated using 
a length scale of inches, then the value of DIAM should be jj. or 0.0S3333 in ordet to 
convert the mesh units to units of feet. If the mesh units are already in feet, then the 
value of DIAM should be simply 1.0. Many mesh generation systems for turbomachinery 
geometries nondimensionalize the mesh by a reference diameter determined from the tur- 
bomachinery geometry such that the maximum value of any radial coordinate in the mesh 
is 0.5. In this case, the value of DIAM should be the diameter of the t urbomachine in feet 
used to nondimensionalize the mesh. Proper specification of the DIAM value is critical 
to achieve the correct flow Reynolds number and rotational speed for rotating geometries. 
Many problems can be traced to improper specification of the DIAM value and the user 
should take care to understand the use of this keyword. When in doubt, the user should re- 
member the simple rule that the actual mesh units, when multiplied by the value of DIAM 
should result in physical lengths expressed in feet. 

ENDINPUT 

ENDINPUT 

When the ADPAC07 program encounters the keyword ENDINPUT. the parser which 
searches each line for a valid input keyword string is terminated, and no additional input file 
lines are parsed for input keyword values. Any lines following the ENDINPUT statement 
are ignored, except when t he graphics display system is in effect across a network, in which 
case the statements following the ENDINPUT statement must contain two blank lines 
and the Internet network address of the destination display device (see Chapter 9 for a 
description of the Interactive Graphics Display option). 

EPSTQT 

(Default Value - 0.1) 

EPST0T =0.1 

The EPSTOT keyword determines the value of the smoothing coefficient employed in the 
post multigrid smoothing algorit hm described by the t rigger FTOTSM. This coefficient is 
only used when FTOTSM = 1.0. The value of the coefficient may be any positive number, 
but for most circumstances, a value between 0.0 and 0.25 is suggested (larger values imply 
more smoothing). This option is normally employed for enhanced code stability during the 
multigrid solution process. 


EPSX. EPSY. EPSZ 

(Default Value = 1.0) 
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Body-Centered Mesh Block 
Turbulence Model Nomenclature 

XTRANSS 



X 

i direction 


Figure 3.1: ADPAC07 Body-Centered Mesh Turbulence Model Nomenclature Summary 
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EPSX =1.0 
EPSY =1.0 
EPSZ =1.0 

The EPSX, EPSY, EPSZ keywords set the value of ihe implicit residual smoothing 
coefficient multipliers in the /. j . and k coordinate directions, respectively. 1 he values 
of EPSX, EPSY, and EPSZ are used as simple multipliers for the residual smoothing 
coefficients calculated bv the eigenvalue scaling residual smoothing scheme described in the 
Final Report [1], If EPSX, EPSY or EPSZ = 0.0. then no smoothing is applied for the 
given coordinate direction. The user should be aware that the keyword variable FRESID 
controls the global application of residual smoothing in the solution algorithm, and in the 
case where FRESID=0.0 (residual smoothing disabled), the EPSX, EPSY, EPSZ have 
no impact on ihe solution. The default value for t he coefficient multipliers is 1.0. Any value 
larger than 1.0 simply implies excess smoothing and may be useful for cases with poor 
convergence or undesirable mesh qualily. 11 a value larger than 4.0 is lequiied to stabilize a 
solution, this generally indicates some sort of problem in the calculation (such as poor mesh 
aspect ratio, bad boundary specification, etc.), or might suggest that FRESID has been 
set to 0.0. Values less than 1.0 will likely cause code instabilities for values of CFL greater 
than 2.0. Occasionally for cylindrical coordinate system solutions involving a centerline or 
sting with very small radii, the value of EPSX, EPSY, EPSZ which corresponds to the 
"radial" direct ion must be reduced to 0.2o-0.5 to maintain stability. 

F2EQ 

(Default Value = 0.0) 

F2EQ =0.0 

The F2EQ keyword assigns a trigger which determines the activation of tin' two-equation 
[kU) turbulence model. This turbulence model can provide superior prediction of turbulent 
flows with separation, but at a substantially larger computational cost. The two-equation 
model utilizes additional specification of data at inflow boundaries (see e.g. INLETT, 
INLETG to prescribe the “freest ream” turbulence level, and the turbulent viscosity is 
updated through the solution of two additional transport equations and a "point-wise eddy 
viscositv evaluation (for additional details, see the Final Report [21]). The two-equation 
model is not enabled when F2EQ=0. and is enabled when F2EQ=1.0. 

FBCONF 

(Default Value = 99999.0) 

FBCONF = 99999.0 

The FBCONF keyword assigns a trigger which determines the iteration number at which 
t he boundary conditions are frozen. This trigger was added for those cases where conver- 
gence is apparently hindered by “noise" from the boundary conditions. Caution must be 
exercised when using the FBCONF variable due to the fact that the ADPAC07 code could 
ultimately diverge when all of the boundary conditions are frozen. This option is normally 
only used for debugging purposes. 

FBCWARN 

(Default Value = 1.0) 
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FBCWARN =1.0 

The FBCWARN keyword assigns a trigger which controls the error checking for outer 
block boundary conditions normally performed by the ADPAC07 code prior to execution. 
Following initialization, ADPAC07 normally processes each mesh block and checks to see 
if the user has adequately specified boundary conditions over the six outer surfaces of each 
mesh block. If any portion of an outer boundary does not have some type of boundary con- 
ditions specified, an error message is normally issued and the code will terminate processing. 
Under some conditions, the user may have intentionally neglected to specify a boundary 
condition on an outer mesh block surface, and it is therefore convenient to eliminate this 
error processing. The FBCWARN trigger controls the actuation of this error handling 
facility. When FBCWARN=1.0, the error handling is enabled. When FBCWARN=0.0, 
the error handling is disabled. 

FCARB (NUM) 

(Default Values = 0.0) 

FCARB (1) = 1.0 
FCARB (2) =0.0 
FCARB (3) =0.0 
FCARB (4) =0.0 
FCARB (5) =0.0 

The keyword FCARB( NUM) sets a block specific trigger for the mesh block number 
specified by NUM which determines, on a block by block basis, whether the Cartesian 
(FCARB(AT'M) = 1.0) or the cylindrical (FCARB( A7T/) = 0.0) solution algorithm is 
employed by that block. The ADPAC07 code permits mixed cylindrical and Cartesian so- 
lution blocks in a single calculation. While the variable FCART may be used to set the 
global value of mesh blocks for either cylindrical or Cartesian solution status, the variable 
FCARB( NFM) may be utilized to set specific blocks one way or the other. It must be 
noted that the variable FCARB( A 7 CA/) will always override the status implied by FCART. 
At present , the only boundary condition which permits interblock communication between 
mixed cylindrical and Cartesian blocks is BCPRR (see Section 3.7). 

FCART 

(Default Value = 0.0) 

FCART =0.0 

The FCART keyword assigns a trigger which controls the cylindrical/Cartesian coordinate 
system solution scheme in the the ADPAC07 code. If FCART = 0.0, then all blocks 
(except those specifically altered by the FCARB input variable) are treated as cylindrical 
coordinate system blocks. If FCART = 1.0, then all blocks (except those specifically 
altered by the FCARB input variable) are treated as C artesian coordinate system blocks. 

FCOAGl 

(Default Value = 1.0) 


FCOAGl =1.0 
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The FCOAG1 keyword specifies the initial, or coarsest coarse mesh level upon which the 
“full" multigrid calculation is initially applied (for additional details, see the description of 
FFULMG). When multiple coarse mesh levels are available for processing, it is occasionally 
useful 1 o specify the initial coarse mesh level in the “full” mulligrid sequence in order to 
avoid wasted computations on lower mesh levels. Typically. FCOAG1 is set to FMULTI 
(start ''full" multigrid on coarsest mesh level). In some cases (when FMULTI is larger than 
:{.()) it may be advisable to set FCOAG1 to 3.0. and avoid additional processing on coarser 
meshes during the ''full" multigrid startup process. A flowchart of the AD PA ('07 iteration 
and multigrid cont rol algorithm is given in Figure 3.2. An example is given in the description 
of FCOAG2. 

FCOAG2 

(l)efault Value = 2.0) 

FC0AG2 =2.0 

The FCOAG2 keyword specifies the final, or finest coarse mesh level upon which the "full" 
multigrid calculation is applied (for additional details, see the description of FFULMG). 
When multiple coarse mesh levels are available for processing, it is occasionally useful to 
specify the final coarse mesh level in the "full" multigrid sequence in order to examine the 
flowfield without actually performing any calculations on the fine mesh, for example, the 
combination 

FMULTI =3.0 
FC0AG1 =3.0 
FC0AG2 =3.0 
FNCMAX =10.0 
FITFMG = 100.0 

would direct a “full" mult igrid startup of 100 iterations on mesh level 3, and since FCOAG2 = 3.0. 
the “full” multigrid sequence is ended at this mesh level. The solution is then interpolated 
to the fine mesh, and then 10 fine mesh iterations using 3 levels of multigrid would be per- 
formed. Typically. FCOAG1 is set to 2.0. which indicates that the “full" multigrid startup 
procedure utilizes all mesh levels from FCOAG1 to 2 before starting any processing on the 
fine mesh. A flowchart of the . 1 1)P. \C()7 iteration and multigrid control algorithm is given 
in Figure 3.2. 

FCOCOM 

(Default Value = 0.0) 

FCOCOM =0.0 

The FCOCOM keyword assigns a trigger which determines the method by which cell face 
areas and cell volumes are determined for the coarse mesh levels of a multigrid solution. 
When FCOCOM=().(). coarse mesh cell face areas and cell volumes are determined in 
exact ly the same manner as the fine mesh ( using the X mesh points defining t he vertices of the 
cell and computing a series of cell face diagonal cross products for the areas, and computing 
a cell center and additional dot products for the cell volume). When FCOCOM=l.(). the 
coarse mesh cell face areas and cell volumes are computed by summing the cell face areas 
and cell volumes of the enclosed fine mesh cells relative to each coarse mesh cell. 1 he 
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procedure defined by FCOCOM = 1.0 is believed to be a more consistent representation of 
the coarse to fine mesh injection/interpolation process, but experience has not shown any 
great difference using either method. 

FCONVRG 

(Default Value = -100.0) 

FCONVRG = -7.0 

The FCONVRG keyword specifies the log 10 root -mean-square residual level at which 
the solution is deemed converged. The solution convergence is monitored and when the log 
10 root-mean-square residual level is less than FCONVRG, the time-marching process is 
terminated and the solution is output. In general, the solution should not be considered 
converged unless the log 10 root-mean-square residual is less than -0.0. The authors do not 
recommend the use of this variable for explicit time-dependent, calculations. The FCON- 
VRG variable is useful for terminating the inner iterations of an implicit time-dependent 
solution. 

FDEBUG(ATOO 

(Default Values = 0.0) 

FDEBUG(l) = 0.0 
FDEBUG(2) =0.0 
FDEBUG(3) =3.0 
FDEBUG(4) =0.0 
FDEBUG(5) =0.0 

The keyword FDEBUG( TYPE) defines a block number for the debug output type specified 
by TYPE which determines, on a type by type basis, whether debug output from the 
ADPAC07 run is printed to the standard out put. When enabled, this variable will generate 
an extreme amount of output and should t herefore be used only in a controled debugging 
environment. The value of the variable FDEBUG( TYPE) determines for which blocks 
the particular type of output is enabled. The following debug output types are currently 
supported: 

FI)EBUG(l) Print the input (Cartesian) mesh points 
FDEBUG(2) Print the (converted) cylindrical mesh points 
FDEBUG(3) Print the cell face areas 
FDEBUG(4) Print the cell volumes 
FDEBUG(5) Print the cell flow data 
FI)EBUG(b) Print the cell time steps 
FDEBUG(7) Print the cell convective fluxes 
FDEBUG(S) Prin the cell dissipative fluxes 
FDEBUG(9) Print the cell diffusive fluxes 
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FI)EBUG(IO) Print the cell implicit residual smoothing data 

FDELTAT 

(Default Value = 0.0) 

FDELTAT = 1.0e-7 

The FDELTAT keyword assigns the value for the physical time increment (in seconds) 
used during a time-dependent solution (either explicit or implicit ). For explicit solutions, 
it is up to the user to ensure that the value of FDELTAT does not violate the stability 
characteristics of the explicit flow solver. For implicit solutions, this value should reflect 
a reasonable number of global time steps over the course of the unsteady aerodynamic 
phenomena of interest . 

FDESIGN 

(Default Value = 0.0) 

FDESIGN =0.0 

The FDESIGN keyword assigns a trigger which determines directly whether to use the 
body force design system calculation procedure developed under Task IK of NASA Contract 
NASS- 25950. When enabled, this option dictates that a. solution be performed on a 2-D 
axisvmmetric grid representative of a throughflow calculation for a turbomachinery flow- 
path. The solution requires t he input of a body force file (see the description of BFFILE) 
which specifies t he blade blockage (a. description of the contents of a body force file is given 
in Section 5.9). The 2-D grid must be constructed such that it represents the 2-D hub to 
tip mean flow stream surface. In other words, if the mean flow involves swirl, then the grid 
is warped in the circumferential direction to indicate the degree of swirl represented by the 
mean stream surface. The A I) PA ('07 flow solver then iteratively updates the body forces 
internal to the code until the predicted mean stream surface matches the mean stream sur- 
face defined by the mesh. This feature was developed for ttse in a design-like environment 
wherein gross flow properties such as turning may be known, but specific airfoil shapes may 
nol be known. 


FFAST 

(Default Value = 0.0) 

FFAST =0.0 

The FFAST keyword assigns a trigger which incorporates some simplifications of the AD- 
PAC07 mult igrid algorithm which reduces the CPU time per multigrid cycle. The CPI 
savings afforded when this option is enabled (FFAST=1.0) is estimated to be about 20%. 
Unfortunately, the ADPAC07 algorithm is less stable using the procedures enabled by 
FFAST=1.0 and in general, this option is not recommended. 

FFILT 

( Default Value = 1.0) 


FFILT =1.0 
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The FFILT keyword assigns a trigger which determines directly whether the added dissipa- 
tion routines are called during the time-marching process. If FFILT — 0.0, then no added 
dissipation is calculated. It is also possible to turn off the added dissipation by setting the 
values of VIS2 and VIS4 to 0.0; however, the use of FFILT avoids the calculation of the 
dissipation terms entirely. It is unlikely that, any value other than 1.0 is required except for 
code debugging purposes. 

FFULMG 

(Default Value = 0.0) 

FFULMG =0.0 

The FFULMG keyword assigns a trigger which determines whether the “fulF multigrid 
solution procedure is applied or whether the standard multigrid procedure is used. The use 
of “full" multigrid is advisable (but not required) when a new calculation is being started 
as a means of rapidly generating a better initial guess for the final flowfield. If the solution 
is being restarted from a previous calculation (FREST=1.0). it is usually advisable to set 
FFULMG to 0.0 to avoid destroying the initial data read from the restart file (a warning 
message is issued when this combination is specified ). A flowchart of the ADPAC07 iteration 
and multigrid control algorithm is given in Figure 4.2. 

FGRAFINT 

(Default Value =1.0) 

FGRAFINT =1.0 

The FGRAFINT keyword determines the number of iterations between flowTeld display 
updates for the ADPAC07 real time graphics display system. This option is only valid 
when FGRAFIX = 1.0. and is subject to a number of other restrictions for the graphics 
display system (see the description of input keywords FGRAFIX and FIMGSAV. and the 
description of the graphics display system. Chapter 9). The default value for FGRAFINT 
is 1.0, which indicates that the graphics display wall be updated every iteration. This can 
cause excessive computational and network overhead, and the user should be aware of the 
potential problems when using the graphics display features. The use of the graphical 
display features of the AD PACO 7 code are not generally recommended. 

FGRAFIX 

(Default Value = 0.0) 

FGRAFIX =0.0 

The FGRAFIX keyword sets a trigger which controls the generation of the real time 
interactive graphics display in the ADPAC07 program. A value of FGRAFIX = 1.0 
indicates that the interactive graphics display facility is desired, while FGRAFIX = 0.0 
turns this option off. When functional, the graphics screen is updated with the latest 
available flow data every FGRAFINT iterations. Graphics images can be automatically 
captured on specific computer hardware every FIMGSAV iterations as a means of creating 
flowfield animations (see Graphics Display. Chapter 9). In order for the graphics display to 
work, the code must be compiled with either the graphics or pfagraphics Makefile option (see 
Section 3.4 for a description of the Makefile and the ADPAC07 code compilation process). 
There are also specific machine requirements for this option to work as well (see the section 
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on Graphics Display. Chapter 9). The generation of interactive, real time graphics images 
increases the overall computational cost, and can cause network overloading in some cases 
due to the transmission of graphics information. The use of the graphical display features 
of the ADPAC07 code are not generally recommended. 

FIMGINT 

(Default Value = 99999.0) 

FIMGINT = 99999.0 

The FIMGINT keyword determines the number of iterations between flowfield graphics 
display image capturing available on Silicon Graphics computers for the .1 1) FA ('07 real time 
graphics display system. T his option is only valid when FGRAFIX = 1 .0, and FIMGSAV 
= 1.0, and is sub ject to a number of other restrictions for the graphics display system (see 
the description of input keywords FGRAFIX and FGRAFINT. and the description of 
the graphics display system. Chapter 9). The default value for FIMGINT is 99999.0. 
which indicates that a screen image will be saved every 99999 iterations. This large value 
was chosen to prohibit accidental image capturing, which can quickly (ill up a large amount 
of disk storage. The graphics display system can cause excessive computational and network 
overhead, and the user should be aware of the potential problems when using this feature 
of the ADFAC07 code. The use of the graphical display features of the A I) FA ('07 code are 
not generally recommended. 

FIMGSAVE 

(Default Value = 0.0) 

FIMGSAV =0.0 

The FIMGSAV keyword sets a trigger which controls the Silicon Graphics computer screen 
image capturing facility of the real time interactive graphics display in the ADFAC07 pro- 
gram. A value of FIMGSAV = 1.0 indicates that the graphics image capturing facility is 
desired, while FIMGSAV = 0.0 turns this option off. When the interactive graphics display 
option has been enabled (see details for input keywords FGRAFIX, FGRAFINT) the 
graphics screen is updated with the latest available flow data every FGRAFINT iteration. 
When the image capturing facility is enabled, these graphics images can be automatically 
captured on specific computer hardware every FIMGINT iterations as a means of creat- 
ing flowfield animations (see Graphics Display, Chapter 9). In order for the graphics display 
image capturing facility to work, the code must be compiled with either the graphic.*, or 
pfagraphics Makefile option (see Section 3.4 for a description of the Makefile and the AD- 
FA ( ‘07 rode compilation process). There are also specific machine requirements for this 
option to work as well (see t he section on Graphics Display. ( hapter 9). I he generation 
of interactive, real time graphics images increases the overall computational cost, and can 
cause network overloading in some cases due to the transmission of graphics information. 
The capt uring of many screen images will also require a large amount of file storage space 
(see Section 3.5 for a description of the image capturing file naming convention). The use 
of the graphical display features of the ADFAC07 code are not generally recommended. 

FIMPFAC 

(Default Value = '2.0) 


FIMPFAC =2.0 
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The FIMPFAC keyword is a simple trigger which determines the degree of time-accuracy 
employed in the implicit solution algorithm enabled by the keyword FIMPLIC. There are 
four options available for this keyword. Values of 1.0 and 2.0 utilize the “fully*' implicit 
strategy described in [21] and are first and second order accurate in time, respectively. 
Values of -1.0 and -2.0 utilize a “lagged" “fully" implicit strategy (thought to improve 
stability) and are first and second order accurate in time, respectively. 

FIMPLIC 

(Default Value = 0.0) 

FIMPLIC =0.0 

The FIMPLIC keyword is a simple trigger to determine whether the iterative implicit 
solution mode is enabled (enabled when FIMPLIC= 1.0). The implicit algorithm is used 
only for time dependent flow calculations, and requires that the additional input flow 
variables FDELTAT, and FNTSTEP be specified. The ADPAC07 code must also be 
compiled with array parameter FIMPRA set to 1 to properly allocate array storage in 
the code. When enabled, the implicit algorithm performs a global time marching loop 
strategy whereby each interation of the global loop involves an iterative solution of a pseudo 
steady state problem using the standard explicit time-marching strategy. The features of 
this inner iteration problem is still governed by input variables such as CFL, CFMAX, 
FMULTI, FNCMAX. etc. The global time increment for the outer loop is set by the 
value of FDELTAT. The implicit algorithm occasionally exhibits unstable behavior and 
the solution should initially be closely monitored. The user should fully understand the 
implications and use of the implicit algorithm before attempting to utilize this option. A 
theoretical description of the procedure is given in Reference [21]. 

FINVYI 

(Default Value — 0.0) 

FINVVI =0.0 

The FINVVI keyword is a simple trigger to determine whether the solution mode is for 
inviscid flow (FINVVI = 0.0) or for viscous flow (FINVVI = 1.0). This trigger con- 
trols whether the viscous stress flux contributions are calculated during the time-marching 
process. This does not affect the application of boundary conditions, as this is completely 
controled by the specifications in the boundary data file (see Section 3.7). As such, it is pos- 
sible to run viscous boundary conditions in an inviscid flow solution, and inviscid boundary 
conditions in a viscous flow solution. 

FITCHK 

(Default Value = 100.0) 

FITCHK = 100.0 

The FITCHK keyword controls the number of iterations between job checkpointing in 
the ADPAC07 program. Job checkpointing refers to the process of periodically saving 
the flowfield information to minimize the loss of data in the event that the job does not 
terminate normally. As a safety feature, the ADPAC07 program writes out an updated 
restart file every FITCHK iterations in case the job stops before the final restart file 
output procedures are completed. It is not necessary to write out intermediate restart files. 
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but tliis is considered a good precaution against unexpected problems such as computer 
failures, or system administration quotas. A good interval for checkpointing is 100 iterations 
(FITCHK - 100. 0). The intermediate restart files, as well as the final restart file, are all 
written to the same file name, and therefore previous checkpoints cannot be retrieved when 
the file is overwritten (see Section To for restart file naming conventions). Job checkpointing 
only applies to the iterative cycles involving the fine mesh, and does not apply to the coarse 
mesh iterations calculated during a "full" multigrid startup (see FFULMG ). 

FITFMG 

(Default Value = 100.0) 

FITFMG = 100.0 

The FITFMG keyword dictates the number of iterations to be performed on each of 
the coarse mesh levels during a “full" multigrid startup sequence (see the description of 
FFULMG). Typically, the startup sequence is used only to generate a reasonable initial 
guess for the fine mesh, so the value of FITFMG is kept relatively low (~ 100). 1 he 

function of the keyword FITFMG is illustrated graphically in f igure -1.2. 

FMASSAVG 

(I)efault Value = TO) 

FMASSAVG =3.0 

The FMASSAVG keyword describes a. trigger which determines the type of mass averaging 
used in the .1 1) FAC 01 code for various boundary conditions. In particular, the MBCAVG 
boundary condition which imposes a circumferential mixing plane for simplified representa- 
tion of multistage turbomachinery blade row flows is the most commonly affected routine. 
A value of FMASSAVG = 0.0 implies t hat an algebraic average is to be used in the av- 
eraging operator in the ADPAC'O ? code. A value of F1V1ASSAVG — 1.0 implies that an 
area average is to be used in the averaging operator in the ADPACQ7 code. A value of 
FMASSAVG = 2.0 implies that a mass-weighted average is to be used in the averaging 
operator in the ADFAC07 code. Values of 2.0 and TO are recommended, as the algebraic 
average introduces a fair amount of error. 

FMGTSTEP 

( Default Value = 0.0) 

FMGTSTEP = 100.0 

The FMGTSTEP keyword assigns the number of global time steps to be evaluated on 
coarse mesh levels for the implicit flow solver when the "full" multigrid option FFULMG 
is enabled. In the processing of large time-dependent calculations using the implicit flow 
solver, it has been found useful to employ the “full" multigrid type of startup procedure 
for the time-dependent runs as well as the steady state analyses. This basically initializes 
the multiple time levels data arrays such that when the line mesh solution is activated, the 
data in the previous time level arrays are initialized with something other than the current 
solution, and a hopefully better approximation of the time-derivatives can be performed. 
FMGTSTEP sets the number of implicit t ime steps performed on the coarse meshes during 
the “full" multigrid startup. This keyword will only be active when FIMPLIC= 1 .0. and 
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FFULMG= 1.0. For a more detailed description of the “full" multigrid startup procedure, 
see the descriptions of FFULMG. FCOAGl. FCOAG2. and Section 2.5. 

FMULTI 

(Default Value = 1.0) 

FMULTI =1.0 

The FMULTI keyword assigns the number of multigrid levels to be used during the cal- 
culation (for a description of the multigrid algorithm, see Reference [4]). The code will 
analyze the dimensions of the fine mesh to determine whether it can be properly subdi- 
vided according to t he number of multigrid levels requested. If FMULTI < 1.0. then the 
number of multigrid levels is set to 1, and the calculation is performed on the finest mesh 
only without multigrid acceleration. For unsteady flows using the explicit time-marching 
strategy, the current multigrid scheme is not valid, and FMULTI should be set to 1.0. For 
time-dpendent flows based on the implicit time-marching strategy (FIMPLIC=1.0). the 
multigrid algorithm may be enabled as with any steady state solution. A flowchart of the 
.4 DPA CQ7 iterat ion and mult igrid control algorithm is given in Figure 3.2. 

FNCMAX 

(Default Value = 100.0) 

FNCMAX = 100.0 

The FNCMAX keyword controls the total number of iterations for a non- multigrid cal- 
culation (FMULTI < 1.0), or the number of global iterations on the finest mesh for a 
multigrid calculation (FMULTI > 1.0). The total number of iterations performed on 
all meshes for a multigrid run is controled by a combination of FNCMAX, FMULTI, 
FCOAGl, FCOAG2. FFULMG, FITFMG, and FSUBIT. For example, the values 

FNCMAX = 200.0 
FMULTI =1.0 
FITFMG =0.0 
FFULMG =0.0 
FSUBIT =0.0 

would prescribe 200 iterations of a non-multigrid run (only the fine mesh is used). The 
values 

FNCMAX = 200.0 
FMULTI =3.0 
FITFMG =0.0 
FFULMG =0.0 
FSUBIT =1.0 

would prescribe 200 multigrid iterations using 3 mesh levels (but still only 200 global iter- 
ations. where each iteration involves a single subiteration on each of 3 mesh levels). And 
finally, the values 
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FNCMAX = 200.0 
F MULTI =3.0 
FITFMG =50.0 
FFULMG =1.0 
FSUBIT =1.0 
FC0AG1 = 3 
FC0AG2 = 2 

would proscribe an init ial pass of 50 iterations on the t hird mesh level, followed by 50 mult i- 
grid iterations on the second mesh level, and finally '200 global multigrid iterations on the 
finest mesh level. See the descriptions of t he variables FNCMAX. FMULTI. FCOAG1. 
FCOAG2. FFULMG. FITFMG. and FSUBIT for further details. A flowchart of the 
ADFAC07 iteration and multigrid control algorithm is given in Figure 3.2. 

FNTSTEP 

(Default Value = 0.0) 

FNTSTEP = 100.0 

The FNTSTEP keyword assigns the number of global time steps to be evaluated on 
the finest mesh during an implicit time-dependent solution. FNTSTEP essentially sets 
the number of global time steps performed (while FNCMAX sets the number of inner 
iterations for each global time step). The total physical time of the time-dependent implicit 
solution is therefore FNTSTEP multiplied by FDELTAT. This variable is only active 
when FIMPLIC= 1 .0. 

FRDMUL 

(Default Value = 0.0) 

FRDMUL =0.0 

The FRDMUL keyword determines whether boundary condition data for the coarse mesh 
levels of a multigrid run are generated from the fine mesh boundary conditions specified 
in the AD FA ('07 boundary data file (FRDMUL = 0.0). or whether the coarse mesh 
boundary specifications are actually read in from the boundary data file ( FRDMUL, — 
1.0). In most cases. FRDMUL should be set to 0.0. and the program will determine 
the equivalent coarse mesh boundary conditions from the fine mesh specifications. l or t he 
purposes of code debugging, or to permit multigrid calculation on a mesh which does not 
possess perfect ‘■multigrid” boundary segments (a boundary condition for the fine mesh does 
not begin or end at a mesh index which is compatible with the multigrid sequence), it is 
possible to “fool" the program into running multigrid by artificially specifying an equivalent- 
coarse mesh boundary condition. 

FRESID 

( Default Value = 1.0) 

FRESID =1.0 

1’he FRESID keyword assigns a trigger which determines directly whether the implicit 
residual smoothing routines are called during the time-marching process. If FRESID = 
0.0. then no residual smoothing is applied. It is also possible to turn off the residual 
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ADPAC Input Keyword Multigrid Cycle 
and Time-Marching Iteration Management Flowchart 


FMULTI = 1.0 



No 

FNCMAX iterations 
on fine mesh (level 1 ) only 


Interpolate to fine mesh level 


6 


FNCMAX iterations on 
fine mesh (level 1) using 
FMULTI levels of multigrid 
with FSUBIT subiterations 
on each coarse mesh level 



FFULMG = 0.0 / ' \ FFULMG = 1.0 

Multigridy 


FTTFMG iterations on mesh level 
FCOAG1 using (FMULTI-FCOAG1+1) 
levels of multigrid with FSUBIT 
subiterations on each coarse mesh level 

Interpolate to next mesh level 

FITFMG iterations on mesh level 
FCOAG1-1 using (FMULTI-FCOAG1+2) 
levels of multigrid with FSUBIT subiterations 
on each coarse mesh level (repeat as needed) 

Interpolate to next mesh level 


FITFMG iterations on mesh level 
FCOAG2 using (FMULTI-FCOAG2+1) 
levels of multigrid with FSUBIT 
subiterations on each coarse mesh level 




Figure ADPAC07 input keyword multigrid cycle and t ime-marching iteration manage- 
ment flowchart 
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smoothing by setting the values of EPSX, EPSY. and EPSZ to ().(): however, the use 
of FRESID avoids the calculation of the smoothed residuals entirely. It is unlikely that 
any value other than 1.0 is required except for code debugging purposes, or for calculations 
involving CFL< 2.0. 

FREST 

(Default Value = 0.0) 

FREST =0.0 

fhe FREST keyword assigns a trigger which controls the restart characteristics of the 
ADPAC07 code. If FREST = 0.0. then no restart file is used, and the flow variables 
are initialized according to the scheme described under the input keyword RMACH. If 
FREST = 1.0. then the code attempts to open a restart file {rase. re start. old) described 
by the hie naming convention (see Section 3.5), and the flow variables are initialized by the 
values given in the restart file. Restarting a calculation from a previous calculation is often 
useful for breaking up large calculations into smaller computational pieces, and may also 
provide faster convergence for cases which involve minor changes to a previous calculation. 

A third option is provided (FREST = -1.0) which allows the A DPA C07 to restart from 
a coarser mesh solution restart file. For very large meshes which permit multigrid, it may be 
desirable to initiate the solution using lesser computers by running on a coarsened mesh level 
generated independently from the fine mesh solution (using the CO A USES program ). For 
example, if a solution is ultimately desired on a 257x257x257 mesh, this obviously would 
require a fair amount of computer resources to complete. During the solution initiation 
phase, it might be desirable to start the solution on a coarsened version of the filial fine 
mesh (129x129x129) using a smaller computer (a workstation for example). This can be 
accomplished t hrough the following procedure. First, create a coarse mesh equivalent of the 
desired fine mesh solution (the COAHSFN program was developed for this purpose). Create 
a solution for the coarsened mesh using ADPAC07 using whatever computer is available. 
Next, using the restart file from the coarsened mesh solution, "restart" the fine mesh solution 
using FREST = -1.0. The coarsened mesh must represent, an exact coarsened mesh from 
the ultimate fine mesh (every other mesh line removed) for this procedure to work properly. 

It should be mentioned that restart files generated by the implicit time-dependent so- 
lution strategy will contain additional time level data compared to a steady state restart 
file. It is possible to restart a time-dependent implicit solution from an explicit steady 
state restart file and vice versa, at the expense of some loss of informat ion. For long time- 
dependent solutions involving multiple restarts, the proper restart files must be utilized to 
properly predict the time-dpendent flow behavior. 

FSAVE 

(Default Value = 1.0) 

FSAVE =1.0 

The FSAVE keyword assigns a trigger which controls the restart file output characteris- 
tics of the AD PACO 7 code. If FSAVE = 0.0. then no restart file is written at the end 
of an ADPAC07 run. If FSAVE = 1.0. then the code attempts to open a restart file 
{ease .re start. ne tr) described by the file naming convention (see Section 3.5). and the flow 
variables are written to the restart file for future processing. Restarting a calculation from 
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a previous calculation is often useful for breaking up large calculations into smaller com- 
putational pieces, and may also provide faster convergence for cases which involve minor 
changes to a previous calculation. The recommended procedure is to always write a restart 
file. 


FSQLVE 

(Default Value =1.0) 

FSOLVE =1.0 

The FSOLVE keyword assigns a trigger which determines which type of time-marching 
strategy is employed on both fine and coarse meshes. For FSOLVE = 0.0. the stan- 
dard 4-stage Runge Kutta time-marching scheme is used with a single added dissipation 
evaluation, and implicit residual smoothing at alternating stages. For FSOLVE = 1.0. a 
modified 4-stage Runge Kutta time-marching scheme is used with two evaluations of the 
added dissipation, and implicit residual smoothing at every stage. For FSOLVE = *2.0, 
a 5-stage Runge Kutta time-marching scheme is used with three weighted added dissipa- 
tion evaluations, and implicit residual smoothing at every stage. FSOLVE = 1.0 is the 
recommended value, although the other schemes may provide improved convergence at a 
somewhat different computational cost per iteration. 

FSUBIT 

(Default Value = 1.0) 

FSUBIT =1.0 

The FSUBIT keyword determines the number of subiterations performed on coarse meshes 
during the coarse mesh portion of the multigrid cycle. As such, this variable is actually only 
used when FMULTI > 1.0. Additional subiterations on coarse meshes during the multigrid 
cycle can often improve convergence, at the expense of some additional computational work. 
The number of subiterations specified by FSUBIT is applied at each coarse mesh level 
during the multigrid calculations process. A value of 1.0, 2.0. or 3.0 is typically best. A 
complete description of the multigrid calculation process is given in the Final Report [4], A 
flowchart of the ADPAC07 iteration and multigrid control algorithm is given in Figure 3.2. 

FTIMEI 

(Default Value =1.0) 

FTIMEI =1.0 

The FTIMEI keyword assigns a trigger which determines the number of iterations between 
time step evaluations. For best results, this should be 1.0, which implies that the time step 
is re-evaluated at every iteration. However, this value can be increased (< 10) to reduce 
CPU time by reevaluating the time step every FTIMEI iterations instead (at the possible 
expense of irregular convergence). 

FTIMERM 

(Default Value = 0.0) 


FTIMERM =0.0 
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The FTIMERM keyword is utilized to control CPU quota during a run of the AD- 
FA CO 7 code. The effect of this variable is different during execution on a Cray computer 
and a UNIX workstation. On the Cray, for jobs running under the Network Queuing Sys- 
tem (NQS). any nonzero value for FTIMERM directs the code to determine how much 
CPU time remains allocated to the current job during each time-marching iteration, and 
the AD FAC'D 7 code estimates how much of that CPU time is required to normally shut 
down the current job. If the time remaining to the job allocation is indicated by / I M E. 
and if the time required to shutdown is S1IVT . then the code will evaluate the expression 

7 I M E - S H l 7 ’ + / 7 7 .1 / E R .1 / 

where each term is in CPU seconds. If this expression is less than 0.0. then the code will 
halt the time marching process and attempt to shut down so the various output files can 
be written prior to termination by NQS due to CPU quota. Note that if FTIMERM is a 
negative number, then the code will shut down “early in case additional pioginms must inn 
under a given NQS run. On a UNIX workstation. NQS is usually not available, and in this 
case, the code keeps track of accumulated CPU time and terminates normal job processing 
when the accumulated CPU time exceeds the value of FTIMERM. If FTIMERM=().(). 
then no action is taken under any circumstances. 

FTIMFAC 

(Default Value = 1.0) 

FTIMFAC =1.0 

The FTIMFAC keyword is a coefficient multiplier which determines the limiting time 
step for the implicit iteration strategy enabled by the keyword FIMPLIC. Under most 
circumstances, the pseudo time step (as opposed to the physical time step) employed by 
the implicit inner iteration strategy requires some limiting to prevent instabilities in the 
global time marching process. The value of FTIMFAC is a "safety factor of sorts In 
simply limiting the value of the psuedo time step. Larger values of FIMPFAC imply 
more limiting, and hence improved stability (theoretically). Under no circumstances should 
FTIMFAC ever be less than 1.0. Values of between 1.0 and 10.0 are recommended. Again, 
this value only has meaning when FIMPLIC = 1.0. 

FTQTSM 

(Default Value = 0.0) 

FT0TSM =0.0 

The FTOTSM keyword is used to trigger the post multigrid smoothing algorithm. In 
this scheme, the residual corrections from the multigrid process are combined with the fine 
mesh residuals and are smoothed globally using a simple constant coefficient version of the 
implicit residual smoothing algorit hm. The smoothing coefficient is determined by the value 
of the input keyword variable EPSTOT. The scheme is disabled when FTOTSM has a 
value of 0.0. and is employed when FTOTSM has a value of 1.0. This scheme has been 
found to aid stability, but can actually hinder convergence in some cases. 

FTURBB 

(Default Value = 10.0) 
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FTURBB =10.0 

The FTURBB keyword assigns a trigger which determines the number of iterations before 
the turbulence model is activated. For laminar flow, set FTURBB to a very large number 
(FTURBB > FNCMAX + (FMULTI 1 ) * FITFMG) * FFULMG) so the turbulence 
model is never called. For turbulent flow, the value should be large enough (e.g., > 10) to 
ensure that the solution has developed adequately enough to permit stable implementation 
of the turbulence model (i.e.. the flowfield should at least exhibit the gross characteristics 
(correct flow direction, some boundary layer development ) of the expected final flow before 
the turbulence model is activated). 

FTURBCHT(JVTO) 

(Default Values = 0.0) 

FTURBCHT ( 1 ) =1.0 
FTURBCHT ( 2 ) =0.0 
FTURBCHT (3) =0.0 
FTURBCHT (4) =0.0 
FTURBCHT(5) =0.0 

The keyword FTURBCHT( NUM) sets a block specific t rigger for t he mesh block number 
specified by the value NUM to enable the body-centered mesh turbulence model described 
in Figure 3.1. If FTURBCHT( AT A/) is set to 0.0, the standard turbulence model is used 
for the block specified by NUM. If FTURBCHT(A7 A/) is set to i.O, then the special 
transition and body centered turbulence model is used for the block specified bv XIM. The 
body-centered turbulence model locates the airfoil leading and trailing edges, and utilizes 
axial chord notation in conjunction with the input variables XTRANSS, XTRANPS 
and CMUTSS, CMUTPS to determine the natural transition point on the airfoil. This 
turbulence model was developed during an analysis of surface heat transfer (where transition 
plays a critical role) on a turbine vane cascade using a ( ’-type mesh. The use of this model 
is recommended whenever the mesh topology is compatible with the scheme illustrated in 
Figure 3.1. Note that the “pressure" and “suction" surfaces defined in Figure 3.1 actually 
refer to geometric orientation rather than aerodynamic function. 

It should be noted that these variables will have no effect when FINVVI=0.0 (inviscid 
flow), or when F2EQ = 1.0 (two-equation turbulence model enabled) or when FTURBCHT=0.0 
(transition model not activated). 

FTURBF 

(Default Value = 99999.0) 

FTURBF = 99999.0 

The FTURBF keyword assigns a trigger which determines the iteration number at which 
the turbulence model is frozen. This trigger was added for those cases where convergence is 
apparently hindered by “noise" from the turbulence model. Caution must be exercised when 
using the FTURBF variable due to the fact that the A DPAC07 restart file does not contain 
any turbulent viscosity data. If the ADPAC07 code is restarted from a turbulent flow 
solution when the value of FTURBF is less than the current iteration level, no turbulent 
quantities will be generated and t lie flow will exhibit laminar flow characteristics. In general, 
it is safest to make this a very large number to avoid problems. 
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FTURBI 

(Default Value = 1.0) 

FTURBI =0.0 

The FTURBI keyword assigns a trigger which determines the number of iterations between 
turbulence model evaluations. For best results, this should be 1.0. which implies that 
the turbulence parameters are reevaluated at every iteration. However, this value can 
be increased (< 10) to reduce CPF time by reevaluating the turbulence quantities every 
FTURBI iterations instead (at the possible expense of irregular convergence). 

FUNINT 

(Default Value = 99909.0) 

FUNINT = 99999.0 

The FUNINT key word is used to determine the number of iterations between instanta- 
neous PI, () i ll) absolute flow file output . For a time-dependent calculation, il is often 
desirable to print oul data at several intervals during the course of the solution to examine 
the time-dependent nature of the flow. The A I) PA ('07 program provides a mechanism by 
which a PLOT.il) format flow file can be printed at a fixed iteration interval (the interval 
defined by the value of FUNINT) as a. means of extracting time-dependent data during a 
calculation. For steady flow calculations, it is normally desirable to set FUNINT to a very 
large number, and simply use the final output PLOT! I) format files if needed. For unsteady 
flow calculat ions, ihe value of FUNINT can be highly case dependent, and some numerical 
experimentation may be required to prevent excessive output, or a deficiency in data. The 
file naming convention for the unsteady output files is given in Section 3.5. Proper selection 
of FDELTAT and FUNINT resulting in PLOT3D output files at specific intervals of time 
will likely produce the most useful results. 

FUPWIND 

(Default Value = 0.0) 

FUPWIND =0.0 

The FUPWIND keyword is a simple trigger to activate the upwind differencing scheme 
( on=l .0. off =0.0 ) available for the 2-D mesh block solver in the ADPAC07 code. The 
upwind differencing scheme is a first order scheme available for experimentation only, and 
is not a recommended solution technique for actual flow calculations at this point. 

FVTSFAC 

(Default Value = 2.5) 

FVTSFAC =2.5 

The FVTSFAC keyword determines the value of the viscous time step evaluation fac- 
tor used to stabilize the time- marching solution for viscous flows. This factor is used to 
magnify the importance of the diffusion-related contributions to the time step evaluation 
(larger values suggest larger restrictions due to diffusion related parameters). This factor is 
particularly useful for meshes with rapid changes in grid spacing, and the default value of 
2.5 was prescribed somewhat arbitrarily following numerical experimentation. It is unlikely 
that this value needs modification for most cases. 
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FWALLF 

(Default Value =1.0) 

FWALLF =1.0 

The FWALLF keyword is used to trigger the use of wall functions in the .4 DPAC07 turbu- 
lence model. Wall functions are normally desirable for meshes which are not highly clustered 
near solid surfaces. The ADPAC07 code can determine when the wall function model is 
necessary and will automatically disable the wall function model (even if FWALLF is en- 
abled) in favor of the standard turbulence model wall treatment for meshes with acceptable 
near wall spacing (roughly 0.0001 times airfoil chord for turbomachinery applications). The 
wall function model is not recommended for applications involving significant heat transfer 
or massive flow separation at this point. 

GAMMA 

(Default Value = 1.4) 

GAMMA =1.4 

The GAMMA keyword sets the value for the gas specific heat ratio. For most cases 
involving air at moderate pressures and temperatures, a value of 1.4 is adequate. For cases 
involving combustion products, this value may be quite different, and should be considered 
appropriately. Extreme care must be taken when post -processing a calculation which is 
based on a value of GAMMA other than 1.4 as many post processors use an assumed 
value of the specific heat ratio equal to 1.4 {PLOT3D is a common example). It should 
be mentioned that the present version of the code does not permit user specification of the 
fluid viscosity, as the formula for air is hardwired into the code. 

P3DPRT 

(Default Value =1.0) 

P3DPRT =1.0 

The P3DPRT keyword assigns a trigger which determines whether PLOT3D format output 
files are written at the end of a calculation. A value of P3DPRT = 1.0 indicates that the 
output files should be written. Conversely, a value of P3DPRT = 0.0 indicates that the 
PLOT3D format output files should not be written. The PLOT3D output files (see Section 
3.5 for file naming conventions for output files) are useful for graphically examining the 
predicted flow quantities using widely available plotting software such as PLOT 3D* FAST* 
SURF* etc. Occasionally, however, due to disk space limitations or simply to speed up 
execution, it may be desirable to eliminate this output feature, and therefore P3DPRT 
can be used to control this output. 

PREF 

(Default Value = 2116.22) 

PREF = 2116.22 

The PREF keyword sets the dimensional value (in pounds force per square foot) of the 
reference total pressure used to nondimensionalize the flowfield. For viscous flows, this value 
must be accurately specified in order to properly set the nondimensional flow viscosity, (and 
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hence, (lie Reynolds number). For inviscid flow predictions, this value has no real signifi- 
cance because of the similarity of inviscid flows with Mach number. It is very important 
to choose an average representative value for t his variable, such that the nondimensional 
total pressure at any point in the flow is near a value of 1.0. An extended discussion on the 
reason for this choice is given in the description of RMACH. In general, PREF is set to 
the freest ream or inlet flow average total pressure. 

PRNO 

(Default Value = 0.7) 

PRNO =0.7 

The PRNO keyword assigns the value of the gas Prandtl number. For air (and many other 
gases) at moderate pressures and temperatures, a value of 0.7 is appropriate. 

PRTNO 

(l)efault Value = 0.9) 

PRTNO =0.9 

The PRTNO keyword assigns the value of the gas turbulent Prandtl number. The tur- 
bulence model in .1 DFA C07 determines the turbulent thermal conductivity via a turbulent 
Prandtl number and the calculated turbulent viscosity (see the Final Report [•!]). The 
recommended value is 0.9. 


RGAS 

(I)efault. Value = 1 710.20) 

RGAS = 1716.26 

The RGAS keyword sets the dimensional value (in foot-pounds force per slug-degree Rank- 
ine) of the gas constant. The default value is for atmospheric air at standard pressure and 
temperature. This value is used in conjunction with GAMMA in determining the gas 
specific heals at const ant pressure and constant volume. 

RMACH 

(I)efault Value = 0.5) 

RMACH =0.5 

The RMACH keyword value is intended to set an initial or reference flow Mach number. 
This value is used primarily to set the initial freest ream flow variables (density, pressure, 
temperature and axial velocity) for a given calculation based on a fixed Mach number. 
The freest ream values are used to initialize the flowfield prior to the execution of the time- 
marching solver in the absence of a restart file. It should be mentioned that the initial 
data values are assigned based on the assumption that the nondimensional freestream total 
pressure and total temperature are 1.0 where the nondimensional values are referenced to 
the dimensional values determined by the PREF and TREF input variables. This implies 
that it is advisable to set up all input variables (in particular PREF and TREF). and 
boundary data for PEXIT (described in Section 5.7 on boundary data file specifications) 
such that the imposed inlet and exit flow boundary conditions are compatible with the 
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initial conditions derived from RMACH, based on the assumed global nondimensional total 
pressure and temperature. For example, suppose that the desired solution for an internal 
stage compressor rotor has an inlet total pressure of 24 psia. and an exit static pressure 
of 23.5 psia. For compressor designers, these numbers might commonly be referenced to 
standard atmospheric pressure (14.7 psia), resulting in nondimensional upstream total and 
exit static pressures of 1.6326 and 1.5986. respectively. If RMACH is set to 0.5, and the 
reference pressure is 14.7 psia, then the interior mesh points will be initiated with a static 
pressure value of 0.84302. It is unlikely that a stable solution will result when the exit 
static pressure is 1.5986, and the interior static pressure is 0.84302 (reversed flow at the 
exit boundary will result ). A better approach is to specify 24 psia as the reference pressure, 
such that the nondimensional inlet total and exit static pressures are 1.0, and 0.97917. and 
the initial nondimensional static pressure at the interior cells is 0.84302. With these values, 
it is much more likely that a stable solution will result. In addition, the value of RMACH is 
used in conjunction with the value of advance ratio specified by the keyword ADVR, when 
the rotational speed is defined in this manner. In this case, the value of RMACH must be 
the freest ream Mach number associated with the advance ratio specified by ADVR or an 
incorrect rotational speed will be calculated. A common error when using the RMACH 
input variable is to assume that the specification of the reference Mach number will set the 
flow for the case of interest. This is not true, as the boundary condition specifications will 
ultimately determine the flow conditions for any case. 

KPM(NTJM) 

(Default Value = 0.0) 

RPM(l) = 0.0 
RPM(2) = 0.0 
RPM(3) = 0.0 
RPM(4) = 0.0 
RPM(5) = 0.0 

The RPM keyword value determines the rotational speed (in revolutions per minute) of 
the mesh block number specified by the value NUM. The value of RPM is. by nature, a 
dimensional value. Block rotational speeds are, by default, zero, unless either an RPM or an 
ADVR keyword are specified otherwise. The user should be aware that if the mesh has not 
been correctly non-dimensionalized, it is then possible that an incorrect value of rotational 
speed would be used in the calculation (see the description of the keyword DIAM). The 
user should also be aware that this value is sign specific, and many computational problems 
traced to geometries which were rotating the wrong way. The proper orientation for the 
RPM specification is illustrated in Figure 3.10. 

TREF 

(Default Value = 518.67) 

TREF = 518.67 

The TREF keyword sets the dimensional value (in degrees Rankine) of the reference total 
temperature used to nondimensionalize the flow field. For viscous flows, this value must be 
accurately specified in order to properly set the nondimensional flow viscosity, (and hence, 
the Reynolds number). This value is also important for the specification of wall temperature 
used in the viscous wall boundary condition SSVI, SS2DVI (see the description of the 
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boundary data file. Section 3.7). For inviscid flow predictions, this value has no real signifi- 
cance because of the similarity of inviscid flows wit h Mach number. It is very important to 
choose an average representative value for this variable, such that the nondimensional total 
temperature at any point in the flow is near a value of 1.0. An extended discussion on the 
reason for this choice is given in the description of RMACH. In general, TREF is set to 
the freestream or inlet flow average total temperature. 

VIS2 

(Default Value = 1/2) 

VIS2 = 0.5 

The VIS2 keyword defines the value of the second order added dissipation term used in 
the fine mesh time-marching solver (see the Final Report [1]). This value is a simple 
multiplier of the second order dissipation term, and hence, larger values imply more added 
dissipation. Second order dissipation is used mainly to control the solution in the vicinity 
of flow discontinuities such as shock waves, but can also be important in any high gradient 
region. The recommended value is 0 . 5 . but values from 0.0 (no second order dissipation) 
to 2.0 may be necessary. Any value larger than 2.0 is of questionable use, as the added 
dissipation will likely dominate the solution. 

VIS4 

( Default Value = 1 /(id) 

VIS4 = 0.015625 

The VIS4 keyword defines the value of the fourth order added dissipation term used in 
the fine mesh time-marching solver (see the Final Report [4]). This value is a simple 
multiplier of the fourth order dissipation term, and hence, larger values imply more added 
dissipation. Fourth order dissipation is used mainly to provide a background dissipation to 
control the odd/even point decoupling associated with centered differencing schemes. The 
recommended value is 0.015625(1/64), but values from 0.0 (no fourth order dissipation) to 
0.0625 ( 1 /16) may be necessary. Any value larger t han 0.0625 is of questionable use, as the 
added dissipation will likely dominate the solution. 

VISCG2 

Format :( Default Value = 1/S) 

VISCG2 = 0.125 

The VISCG2 keyword controls the value of t he second order added dissipation coefficient 
for coarse mesh subiterations during the multigrid time-marching solution process, Coarse 
mesh subiterations utilize a simpler dissipation scheme than the fine mesh time-marching 
scheme, and therefore, a different damping constant is required. Larger values imply in- 
creased added dissipation. The recommended value is VISCG2 = 0.125, although values 
from 0.0 (no dissipation) to 1.0 are possible. Values larger than 1.0 are not recommended 
as the solution would then likely be dominated by the dissipation. 


XTRANSS' XTRANPS 

(Default Value = 0.0) 
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XTRANSS =0.0 
XTRANPS =0.0 

The XTRANSS, XTRANPS keywords determine the percentage of axial chord at which 
transition is forced to occur for the point transition model in the ADPAC'07 body centered 
mesh turbulence model activated by the keyword FTURBCHT. This simplified transition 
model maintains laminar flow until the percentage of axial chord indicated by XTRANSS, 
XTRANPS is exceeded at which point complete transition is forced. Separate variables are 
provided for the "suction side" and "pressure side", respectively, of the airfoil in question. 

The transition model parameters are illustrated in Figure 3.1. Fully turbulent (nontran- 
sitional) flows should set XTRANSS, XTRANPS to 0.0 (transition occurs at leading 
edge). Other values must be determined on a case by case basis. 

It should be noted that these variables will have no effect when FINVVI=0.0 (inviscid 
flow ). or when F2EQ = 1.0 ( two-equation turbulence model enabled ) or when FTURBCHT =0.0 
(transition model not activated). 

ZETARAT 

(Default Value = 0.6) 

ZETARAT =0.6 

The keyword ZETARAT controls a parameter used in the eigenvalue scaling operator in 
the residual smoothing algorithm (see the Final Report [4]). The value of ZETARAT 
represents the exponent the ratio of two coordinate eigenvalues and therefore large values 
of ZETARAT (> ().(j) imply increased bias for meshes with large differences in coordinate 
spacing while small values of ZETARAT ( < 0.5) imply decreased bias for meshes with large 
differences in coordinate spacing. Normally, values between 0.5 and 0.6 are recommended. 

3.7 ADPAC07 Boundary Data File Description 

The ADPAC'07 boundary data file contains the user-specifiable parameters which control 
the application of boundary conditions on the multiple-block mesh during a time- marching 
solution. These boundary specifications determine the location of solid walls, input/output 
flow regions, and block-to-block communication paths. Prior to a detailed discussion of the 
actual boundary condition specifications, several boundary condition application concepts 
should be explained. It is important to understand how boundary conditions are applied in 
the ADPAC'07 finite volume solution scheme. Finite volume solution algorithms typically 
employ the concept of a phantom cell to impose boundary condit ions on the external faces 
of a mesh block. This concept is illustrated graphically for a 2-D mesh representation in 
Figure 3.3. 

A phantom cell is a fictitious neighboring cell which is utilized in the application of 
boundary conditions on the outer boundaries of a mesh block. Since flow variables cannot 
be directly specified at a mesh surface in a finite volume solution (the flow variables are 
calculated and stored at cell centers, where the corners of a cell are described by the 8 
surrounding mesh points), the boundary data specified in the phantom cell are utilized 
to control the flux condition at the cell faces of the outer boundary of the mesh block, 
and, in turn, satisfy a particular boundary condition. All ADPAC’07 boundary condition 
specifications provide data values for phantom cells to implement a part icular mat hematical 
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2-D Mesh Block Phantom Cell Representation 

# Grid Point 

Grid Line 

— Mesh Block Boundary 
— — — — Phantom Cell Representation 



"Comer" phantom cells cannot be controlled 
through boundary conditions, but must be updated 
to accurately compute grid point averaged values 


Figure 3.3: 2-D mesh block phantom cell representation 
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ADPAC 3-D Boundary Condition Specification 

All block boundary conditions are specified as a grid-defined 
’’patch” on an i=constant, j=constant, or k=constant mesh face 


Boundary condition "patch " 
on a inconstant face 



Boundary condition "patch * 
on an inconstant face 



Boundary condition "patch* 
on a k=constant face 


Patches may be internal to the mesh as well 


Figure 4.1: ADPAC07 3-1) boundary condition specification 
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(if) 


Effect of Ordering in Application of Boundary 
Conditions for ADPAC Code 


Computational Domain 



Boundary condition "A" applied first Boundary condition "B" applied Boundary condition "C" applied 

after boundary condition ”A"- part after boundary condition "B" and 
of boundary condition "A" is ”A"-part of boundary conditions 

overwritten "B" and "A” are overwritten 

Figure .'{.5: Hffect of ordering in application of boundary conditions for t he ADPAC07 code 

boundary condition on the mesh. It should be emphasized that the phantom cells are 
automatically defined within the ADPAC07 code, and the user need not be concerned 
about generating fictitious points within the mesh to accommodate the boundary condition 
application procedure (mesh points need only be generated for the actual flow domain). 

Although boundary conditions are imposed at phantom cells in the numerical solution, 
the boundary specification is still most conveniently de fined in terms of grid points, not 
computational cells. An illustration of the boundary specification method for ADPACOTm 
given in Figure 4.1. All boundary conditions are specified in terms of the grid points on 
either an /=constant. j=constant. or ^constant. mesh surface. In practice, these surfaces 
are typically on the outer boundaries of the mesh block, but it is also possible to impose a 
boundary on t he interior of a mesh block (see the description of the boundary specifications 
KILL and KIL2D. below). 

The third important aspect of the application of boundary conditions in the AD- 
PAC07 code involves the order in which boundary conditions are applied. During the 
execution of the .4 DBA ('07 code, all boundary conditions are applied to the various mesh 
blocks in the order in which they are specified in the cetse . boundata file. As a result, it is 
possible to overwrite a previously specified boundary patch with a different boundary condi- 
tion than was originally specified. This concept is illustrated graphically in Figure 4.5. The 
user must take proper precautions to prohibit accidentally overwriting a desired boundary 
patch as the .4 DP ’A (’07 code cannot distinguish the proper order for the user. 

During code execution, the boundary data file is read one line at a time as a charac- 
ter string, and each string is parsed sequentially to determine the specific program action 
in each case. The boundary data file utilizes a keyword input format, such that any line 
which does not contain a recognizable keyword is treated as a comment line. T herefore, the 
user may place any number of comments in the file (so long as the line does not contain 
a keyword input string in the form described below), and code execution is unaltered. All 
boundary data file lines are echoed to the standard output, and the program response to 
each line is listed when a specific action is taken. A line in the boundary data file can also 
be effectively commented by inserting a ft character in the first column. I herefote the lines 
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PATCH 1 1 K K P M I J 1 17 1 129 1 17 1 129 1 17 

PATCH 2 2 K K P M I J 1 17 1 129 1 17 1 129 1 17 

are acceptable boundary specifications; however, the lines 

#PATCH 1 1 K K P M I J 1 17 1 129 1 17 1 129 1 17 

#PATCH 2 2 K K P M I J 1 17 1 129 1 17 1 129 1 17 

would be neglected. 

All keyword input lines are given in the format listed in Figure 3.6. The actual speci- 
fication in the boundary data file may be free format, as long as the individual parameter 
specifications are given in the correct order and are separated by one or more blank spaces. 

All boundary specifications begin with a line containing 19 variables as outlined by the 

vertical labels in Figure 3.6. A description of the function of each of the variables in the 

boundary specification line is given in the proper order in the section below: 


Description of Boundary Specification Line Variables 


BCTYPE 


LBLOCK1 


LBLOCK2 


LFACE1 


The first variable, BCTYPE. is a character string defining the type of 
boundary condition to be applied to a given mesh block. BCTYPE 
must correspond to one of the reserved boundary condition keywords 
defined later in this section to be a proper boundary specification. If 
BCTYPE is not one of the reserved names, then the boundary speci- 
fication line is ignored. 

The variable LBLOCKl is an integer defining the grid block num- 
ber to which the boundary condition implied by BCTYPE is applied. 
Naturally, this implies LBLOCKl >1, and LBLOCKl < NBLKS, 
where NBLKS represents the last mesh block number. 

The variable LBLOCK2 is an integer defining the grid block number 
from which the boundary condition data implied by BCTYPE and ap- 
plied to mesh block LBLOCKl is obtained. In some cases, a boundary 
specification may involve more than one block (patching two blocks to- 
gether is an example), and the LBLOCK2 variable is provided for this 
purpose. The value of the LBLOCK2 variable is only used in cer- 
tain routines, but it is a good idea to be consistent in every boundary 
specification by duplicating the LBLOCKl value for the LBLOCK2 
variable if only a single mesh block is involved in a boundary specifica- 
tion (If the boundary specification only involves a single block, then set 
LBLOCK2 = LBLOCKl). 

The variable LFACE1 is a single character (one of the letters I. J, or 
I\) specifying the grid plane (/=c constant, ^constant, or /^constant) 
to which the boundary condition is applied in block LBLOCKl. This 
specification determines the grid face to which the boundary specifica- 
tion is applied, based on the method by which boundary conditions are 
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CASE.BOUNDATA FILE 


This file contains case-specific boundary data information. All boundary 
condition applications are represented by 1 or more lines in this file. 


A sample line is given in the highlighted region below: 


This is the keyword 

describing the type of 
boundary condition to 
be applied 

This is the mesh block 
number to which — 
the boundary data 
is applied 

This is the mesh block 
number from which 
the boundary data 
is derived 


This indicates the j 
grid surface (ijJO L 
to which the boundary 
data is applied in block 
LBLOCK1 


B 

L 

L 

L 

L 

L 

L 

L 

L 

L 

L 

M 

M 

N 

N 

M 

M 

N 

N 

C 

B 

B 

F 

F 
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1 

1 
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L 

A 

A 
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P 
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I 

I 

P 

C 

C 

E 

E 

1 

2 

C 

C 

M 

M 
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K 
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2 



1 
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1 

2 

1 

2 

1 

2 


1 

2 

















SSIN 

1 

1 

J 

J 

P 

P 

L 

L 

1 

1 

1 

17 1 

17 

1 

17 1 

17 


These are the beginmg 
and ending indices for 
the corresponding coordinate 
directions in block 
LBLOCKI from which 
boundary data is applied 

These are the beginmg 
and ending indices for 
the remaining coordinate 
directions in block 
LBLOCKI to which 
boundary data is applied 


This is the index in the 
LDIR2 direction for 
boundary data in block 
LBLOCK2 


This indicates the 
grid surface (i,j,k) 
from which the boundary 
data is derived in block 
LBLOCK2 


This indicates the direction 
(+=P, -=M) along the LFACE1 
coordinate which travels towards 
the interior of the flow (away from 
the bounding surface) in mesh 
block LBLOCKI 


This indicates the direction 
(+=P, -=M) along the LFACE2 
cooridinate which travels towards 
the interior of the flow (away from 
the bounding surface ) in mesh 
block LBLOCK2 


These are triggers resverved 
for special use in some 
boundary conditions (usually 
the value IJ, or K, which indicates 
the correspondance of the coordinates 
in mesh block LBLOCK2 with the 
remaining (non LFACE1) coordinates 
in mesh block LBLOCKI 


This is the index in the 
LDIR1 direction for 
boundary data in block 
LBLOCKI 


Figure A DBA (’07 boundary data file specification format 
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implemented in the finite- volume solution scheme (see the discussion 
and figures above). 

LFACE2 The variable LFACE2 is a single character (one of the letters I, J, or I\ ) 
specifying the grid plane ( /^constant. j~ constant, or ^constant) from 
which the boundary condition data is derived in block LBLOCK2. 
This specification determines the grid face from which the neighboring 
block boundary data is derived, based on the method by which bound- 
ary conditions are implemented in the finite- volume solution scheme 
(see the discussion and figures above). Naturally, this variable is only 
useful for boundary specifications involving more than one block. If 
only one block is involved, simply set LFACE2 = LFACE1. 

LDIRl The variable LDIR1 is a single character (one of the letters P or M) 
specifying the direction (P=plus. M=minus) along the LDIRl coordi- 
nate in LBLOCKl which is directed away (towards the interior flow re- 
gion) from the boundary surface patch. The specification of this variable 
is normally automatic when the boundary specification is applied to the 
external surface of a grid block - (LDIRl = P when LlLIM = 1. and 
LDIRl = M when LlLIM = I MX J MX. or KMX. (IMXJMX.KMX 
indicate the maximum indices of the LBLOCKl mesh block in the i. 
j. and h directions, respectively). The intent here is to provide a means 
of specifying which side of the boundary surface plane the interior com- 
putational cells (non-phantom cells) lie on. This specification is made 
by providing the coordinate direction of the interior computational cells 
- the phantom cells are then assumed to lie in the opposite direction. 

LDIR2 The variable LDIR2 is a single character (one of the letters P or M) 
specifying the direction (P=plus, M=minus) along the LDIR2 coor- 
dinate in LBLOCK2 which is away (towards the interior flow region) 
from the boundary surface patch. This variable is only used in boundary 
specifications cases involving more than one mesh block. The specifica- 
tion of this variable is normally automatic when the boundary specifi- 
cation data is obtained from the external surface of a neighboring grid 
block - (LDIR2 = P when L2LIM = I, and LDIR2 = M when L2LIM 
= IMX,JMX. or KMX. (IMX.JMX.KMX indicate the maximum indices 
of the LBLOCK2 mesh block in the i. j . and k directions, respectively). 
The intent here is to provide a means of specifying which side of the 
boundary surface plane the interior computational cells (non-phantom 
cells) lie on. This specification is made by providing the coordinate di- 
rection of the interior computational cells - the phantom cells are then 
assumed to lie in the opposite direction. If the boundary specification 
involves only a single mesh block, then simply set LDIR2 = LDIRl. 

LSPECl The variable LSPECl is a single character (usually L J, K, L, or 
H) which implies some special information about the boundary con- 
dition specification. This parameter is boundary condition dependent. 
The most common application of this variable is in the boundary data 
file keyword PATCH, which provides the cell-to-cell connection for 
two grid blocks with a mating contiguous surface. For boundary con- 
ditions involving more than one mesh block (such as PATCH), it 
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is possible that the connection between blocks may involve connec- 
tions between different grid surfaces, and that the indices in block 
LBLOCK2 correspond to a different coordinate in block LBLOCKl. 
In the case of a PATCH boundary condition, the LSPEC1 variable 
determines the grid coordinate direction in the LBLOCKl mesh block 
which corresponds with the first remaining grid coordinate in mesh 
block LBLOCK2. (The extent of the first remaining coordinate in 
mesh block LBLOCK2 is determined by the values of M2LIM1 and 
M2LIM2 ) 

LSPEC2 The variable LSPEC2 is a single character (usually I. .). K. L. or II) 
which implies some special information about the boundary condition 
specification. This parameter is usually boundary condition depen- 
dent. The most common application ol this variable is in the boundary 
data file keyword PATCH, which provides the cell-to-cell connection 
for two grid blocks with a mating contiguous surface. For boundary 
conditions involving more than one mesh block (such as PATCH), 
il is possible that the connection between blocks may involve con- 
nections between different grid surfaces, and that the indices in block 
LBLOCK2 correspond to a different coordinate in block LBLOCKl. 
In the case of a PATCH boundary condition, the LSPEC2 variable 
determines the grid coordinate direction in the LBLOCKl mesh block 
which corresponds with the second remaining grid coordinate in mesh 
block LBLOCK2. (The extent of the second remaining coordinate in 
mesh block LBLOCK2 is determined by the values of N2LIM1 and 
N2LIM2 ) 

L1LIM The variable L1LIM is an integer specifying the index of the grid in the 
LFACEl direction to which the boundary condition should be applied 
in block LBLOCKl. This value determines the actual mesh index of 
the /=constant. y=constant. or /, —constant mesh face (determined by 
LFACEl) to which the boundary condition is applied in mesh block 
LBLOCKl. 

L2LIM 'The variable L2LIM is an integer specifying the index of the grid in the 
LFACE2 direction from which the boundary condition data is derived 
in block LBLOCK2. This value determines the actual mesh index of 
the /=constant. j=constant. or A— constant mesh face (determined by 
LFACE2) from which the boundary condition data is derived in mesh 
block LBLOCK2. 

M1LIM1 The variable Ml LI Ml is an integer representing the initial index of 
the first remaining grid coordinate direction to which the boundary 
condition is applied in block LBLOCKl. Since the boundary spec- 
ification applies to either an /=constant, ./^constant. or /.—constant 
surface, the variables M1LIM1, M1LIM2, N1LIM1 and N1LIM2 
determine the extent of the patch in the remaining coordinate direc- 
tions. The remaining coordinate directions for block LBLOCKl are 
specified in the natural order. (For example, if LFACEl^/. then the 
variables M1LIM1, M1LIM2 refer to the extenl in the j direction 
and the variables NlLIMl, N1LIM2 refer to the extent in the A - di- 
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M1LIM2 


NlLIMl 


N1LIM2 


rection. If LFACEl— /, then the variables MlLIMl, M1LIM2 refer 
to the extent in the i direction and the variables NlLIMl, N1LIM2 
refer to the extent in the k direction. If LFACE1 = A\ then the vari- 
ables MlLIMl, M1LIM2 refer to the extent in the i direction and 
the variables NlLIMl, N1LIM2 refer to the extent in the j direc- 
tion.) The indices specified in MlLIMl and M1LIM2 must be given 
in increasing order. The indices specified in NlLIMl and N1LIM2 
must also be given in increasing order. 

The variable M1LIM2 is an integer representing the final index of 
the first remaining grid coordinate direction to which the boundary 
condition is applied in block LBLOCK1. Since the boundary spec- 
ification applies to either an /^constant. j=constant. or ^constant 
surface, the variables MlLIMl, M1LIM2, NlLIMl and N1LIM2 
determine the extent of the patch in the remaining coordinate direc- 
tions. The remaining coordinate directions for block LBLOCKl are 
specified in the natural order. (For example, if LFACEl = /. then the 
variables MlLIMl, M1LIM2 refer to the extent in the j direction 
and the variables NlLIMl, N1LIM2 refer to the extent in the k di- 
rection. If LFACE1 = ./. then the variables MlLIMl, M1LIM2 refer 
to the extent in the i direction and the variables NlLIMl, N1LIM2 
refer to the extent in the k direction. If LFACE1 = A\ then the vari- 
ables MlLIMl, M1LIM2 refer to the extent in the i direction and 
the variables NlLIMl, N1LIM2 refer to the extent in the j direc- 
tion.) The indices specified in MlLIMl and M1LIM2 must be given 
in increasing order. The indices specified in NlLIMl and N1LIM2 
must also be given in increasing order. 

The variable NlLIMl is an integer representing the initial index of 
the second remaining grid coordinate direction to which the boundary 
condition is applied in block LBLOCKl. Since the boundary spec- 
ification applies to either an /=constant, ^constant, or A*=constant 
surface, the variables MlLIMl, M1LIM2, NlLIMl and N1LIM2 
determine the extent of the patch in the remaining coordinate direc- 
tions. The remaining coordinate directions for block LBLOCKl are 
specified in the natural order. (For example, if LFACEl=7. then the 
variables MlLIMl, M1LIM2 refer to the extent in the j direction 
and the variables NlLIMl, N1LIM2 refer to the extent in the k di- 
rection. If LFACEl = 7, then the variables MlLIMl, M1LIM2 refer 
to the extent in the / direction and the variables NlLIMl, N1LIM2 
refer to the extent in the k direction. If LFACEl — A . then the vari- 
ables MlLIMl, M1LIM2 refer to the extent in the i direction and 
the variables NlLIMl, N1LIM2 refer to the extent in the j direc- 
tion.) The indices specified in MlLIMl and M1LIM2 must be given 
in increasing order. The indices specified in NlLIMl and N1LIM2 
must also be given in increasing order. For boundaries on 2-1) mesh 
blocks, this must always be 1. 

The variable N1LIM2 is an integer representing the final index of the 
second remaining grid coordinate direction to which the boundary con- 
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M2LIM1 


M2LIM2 


N2LIM1 


dition is applied in l)lock LBLOCK1. Since the boundary specification 
applies to either an /^constant, j=constant, or A'=constant surface, the 
variables M1LIM1, M1LIM2, N1LIM1 and N1LIM2 determine 
the extent of the patch in the remaining coordinate directions. The 
remaining coordinate directions for block LBLOCK1 are specified in 
the natural order. (For example, if LFACE1 = /. then the variables 
MlLIMl, M1LIM2 refer to the extent in the j direction and the 
variables N1LIM1, N1LIM2 refer to the extent in the A direction. 
If LFACE1—/, then the variables MlLIMl, M1LIM2 refer to the 
extent in the i direction and the variables NlLIMl, N1LIM2 refer 
to the extent in the k direction. If LFACE1 = A. then the variables 
MlLIMl, M1LIM2 refer to the extent in the i direction and the 
variables NlLIMl, N1LIM2 refer to the extent in the j direction.) 
The indices specified in MlLIMl and M1LIM2 must be given in in- 
creasing order. The indices specified in NlLIMl and N1LIM2 must 
also be given in increasing order. For boundaries on 2-1) mesh blocks, 
this must always be 2. 

The variable M2LIM1 is an integer representing the initial index of the 
grid coordinate direction in block LBLOCK2 corresponding to the first 
remaining coordinate in block LBLOCK1. For boundary conditions 
involving more than one mesh block, it is possible that the connection 
between blocks may involve connections between different grid surfaces, 
and that the indices in block LBLOCK2 correspond to a different coor- 
dinate in block LBLOCK1. The variables M2LIM1, M2LIM2 con- 
trol the indices in the LSPEC1 direction in block LBLOCK2 which 
correspond to the indices determined bv MlLIMl, M1LIM2 in block 
LBLOCK1. The user should note that it is possible for M2LIM1 

> M2LIM2 and N2LIM1 > N2LIM2 but it is not possible for 
MlLIMl > M1LIM2 and NlLIMl > N1LIM2. If only a single 
mesh block is involved in the boundary specification, set M2LIM1 = 
MlLIMl. 

The variable M2LIM2 is an integer representing the final index of the 
grid coordinate direction in block LBLOCK2 corresponding to the first 
remaining coordinate in block LBLOCKl. for boundary conditions 
involving more than one mesh block, it is possible that the connection 
between blocks may involve connections between different grid surfaces, 
and that the indices in block LBLOCK2 correspond to a different coor- 
dinate in block LBLOCKl. The variables M2LIM1, M2LIM2 con- 
trol the indices in the LSPEC1 direction in block LBLOCK2 which 
correspond to the indices determined by MTLIM1, M1LIM2 in block 
LBLOCKl. The user should note that it is possible for M2LIM1 

> M2LIM2 and N2LIM1 > N2LIM2 but it is not possible for 
MlLIMl > M1LIM2 and NlLIMl > N1LIM2. If only a single 
mesh block is involved in the boundary specification, set M2LIM2 = 
M1LIM2. 

The variable N2LIM1 is an integer representing the initial index of 
the grid coordinate direction in block LBLOCK2 corresponding to 
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the second remaining coordinate in block LBLOCKl. For bound- 
ary conditions involving more than one mesh block, it is possible that 
the connection between blocks may involve connections between dif- 
ferent grid surfaces, and that the indices in block LBLOCK2 corre- 
spond to a different coordinate in block LBLOCKl. The variables 
N2LIM1, N2LIM2 control the indices in the LSPEC2 direction 
in block LBLOCK2 which correspond to the indices determined by 
NlLIMl, N1LIM2 in block LBLOCKl. The user should note that 
it is possible for M2LIM1 > M2LIM2 and N2LIM1 > N2LIM2 but 
it is not possible for M1LIM1 > M1LIM2 and N1LIM1 > N1LIM2. 
If only a single mesh block is involved in the boundary specification, set 
N2LIM1 = NlLIMl. For boundary data on 2-D mesh blocks, this 
must always be 1. 

N2LIM2 The variable N2LIM2 is an integer representing the final index of 
the grid coordinate direction in block LBLOCK2 corresponding to 
the second remaining coordinate in block LBLOCKl. For bound- 
ary conditions involving more than one mesh block, it is possible that 
the connection between blocks may involve connections between dif- 
ferent grid surfaces, and that the indices in block LBLOCK2 corre- 
spond to a different coordinate in block LBLOCKl. The variables 
N2LIM1, N2LIM2 control the indices in the LSPEC2 direction 
in block LBLOCK2 which correspond to the indices determined by 
NlLIMl, N1LIM2 in block LBLOCKl. The user should note that 
it is possible for M2LIM1 > M2LIM2 and N2LIM1 > N2LIM2 but 
it is not possible for MlLIMl > M1LIM2 and NlLIMl > N1LIM2. 
If only a single mesh block is involved in the boundary specification, set 
N2LIM2 — N1LIM2. For boundary data on 2-1) mesh blocks, this 
must always be 2. 

Some boundary condition specifications require additional data beyond that incorpo- 
rated in the boundary specification line. In these cases, described in detail for the specific 
boundary types later in this Section, the additional data is included immediately after the 
boundary specification line. 

A sample ADPAC07 boundary data file containing several keywords is listed below. 


Sample A DPAC07 Boundary Data File 


BLOCKDATA 

FOLLOWS: 





LABELS 










B L 

L 

L 

L 

L 

L 

L 

L 

L 

L 

M 

M 

N 

N 

M 

M 

N 

N 

C 

C B 

B 
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F 
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D 

S 

S 

1 

2 

1 

1 

1 

1 

2 

2 

2 

2 

0 

T L 

L 

A 

A 

I 

I 

P 

P 

L 

L 

L 

L 

L 

L 

L 

L 

L 

L 

M 

Y 0 

0 

C 

C 

R 

R 

E 

E 

I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

M 

P C 

C 

E 

E 

1 

2 

C 

C 

M 

M 

M 

M 

M 

M 

M 

M 

M 

M 

E 

E K 

K 

1 

2 



1 

2 



1 

2 

1 

2 

1 

2 

1 

2 

N 

1 

2 

















T 


# 
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# > The next 

two lines do 

the periodic boundary 

c+ 

p* 

II 

h-L 

II 

h-L 




# 

PATCH 1 1 

K K P M 

I 

J 

1 

17 1 49 

1 17 1 

49 

1 

17 

K=1 

PATCH 1 1 

il 

K K M P 

I 

J 

17 

1 1 49 

1 17 1 

49 

1 

17 

K=KL 

# > Hub surface is at J=1 










w 

SSIN 1 1 

J J P P 

S 

S 

1 

1 1 49 

1 17 1 

49 

1 

17 

Hub 

# 

# > Next two 

lines define 

the blade 

surfaces at 

K=1 , K=17 





# 

SSIN 1 1 

K K P P 

S 

S 

1 

1 17 33 

1 17 17 

33 

1 

17 

K=1 

SSIN 1 1 

ji 

K K M M 

S 

S 

17 

17 17 33 

1 17 17 

33 

1 

17 

K=KL 

# 

# > Set the 

inflow data at I 

= 1 








# 

INLETT 1 1 

I I P P 

s 

s 

1 

1 1 17 

1 17 1 

17 

1 

17 

INL 

NDATA 











3 

RAD 

PTOT 

TTOT 


BETAR 

BETAT 





0.100000 

1.000000 

1 . 

000000 

0.000000 

0,000000 





0.300000 

1.000000 

1. 

000000 

0.000000 

0.000000 





0.500000 

1.000000 

1 . 

000000 

0.000000 

0.000000 






# 

#---> Set the exit flow data at 1=49 (Note that the exit static pressure 

# is set here: this determines the blade loading and the flow rate 

# 

EXITT 1 1 I I M M H H 49 49 1 17 1 17 1 17 1 17 INL 

PEXIT 
1.200000 

# 

# > Define the case surface at J=17 

# 

SSIN 1 1 J J M M S S 17 17 1 49 1 17 1 49 1 17 Case 

# 

#---> That's all folks 

# 

ENDDATA 

A list and description of all valid boundary data keywords and any additional data 
required for the given boundary condition is now presented in the pages which follow. 
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BCINTl 

BCINTl Type Noil-Contiguous Mesh Block Interface Patching 
Scheme 




Non~Contiguous Mesh Block Interface Along 
Wake Cut Line Can Employ a BCINTl Specification 
(illustrated in Boundary Data File Format 
statements below) 


Application 

The BCINTl specification is used in any application involving neighboring mesh blocks 
with a non-contiguous grid line to grid line interface in one coordinate direction. The 
interface must be contiguous in the other direction. BCINTl patches one block to one 
other block by interpolation along the non-contiguous index. 

The example graphic above illustrates a two-dimensional mesh system used to predict 
the flow through a turbine vane passage. The (’-type mesh utilizes a noncontiguous wake cut 
line as shown in the trailing edge detail. The BCINTl specification is applied along either 
side of the wake cut line to permit communication of flow variables across the noncontiguous 
mesh interface. Here, the interpolation direction is /. and part of the block is patched to 
itself. Note that the i index increases in different directions at the wake cut line. BCINTl 
can handle interpolation along any index, regardless of the orientation of the mating surface. 



A DP A CO 7 Boundary Data FiU Specifications - BCINTI 


Boundary Data File Format 


The boundary data file specifications for the ntesli interface indicated in the illustrative 
graphic for the BCINTI boundary condition are given below: 

BCINTI 1 1 J J P P L L 1 1 1 33 1 2 193 177 1 2 

IDIRNT1 IDIRNT2 
I I 

ISHFTDR DSHIFT 

2 0.0 

BCINTI 1 1 J J P P L L 1 1 177 193 1 2 33 1 1 2 

IDIRNT1 IDIRNT2 
I I 

ISHFTDR DSHIFT 

2 0.0 

Note that a complete BCINTI specification generally requires two BCINTI statement 
lines in the boundary data file. In the example above, the first specification provides the 
interblock communication for one side of the ( -grid wake cut, while the second specification 
provides the communication for the other side of the (’-grid wake cut. It is a common error 
to underspecify a BCINTI boundary by only providing a single line per interface. 


Description 

The BCINTI boundary statement provides a means for block to block communication 
for cases involving neighboring mesh boundaries which share a common surface, but are 
non-contiguous in one grid index. BCINTI can be applied to either stationary or rotating 
block interfaces, but the results are physically correct only if both blocks are rotating at 
the same speed. (The BCPRR specification should be used for cases with relatively ro- 
tating blocks.) A proper BCINTI boundary is specified much like a PATCH boundary. 
The LFACE1 and LFACE2 determine which faces are mated together. BCINTI also 
requires the specification of additional information. The second line in a BCINTM speci- 
fication is a comment line, normally labeling the variables INTDIR1 and INTDIR2. The 
third line defines the variables INTDIR1 and INTDIR2 as either I . .7, or A , depending 
on the direction of interpolation for the receiving and sending blocks, respectively. One 
mesh restriction to note is that BCINTM allows only one interpolation direction for each 
side of the interface. The fourth line is a comment line normally labeling the variables 
ISHFTDR and DSHIFT. The fifth line defines the values for the variables ISHFTDR 
and DSHIFT. 'These variables provide a mechanism for shifting the boundary in one of 
the three coordinate directions (.wy.z for (artesian flows, or j\r,0 for cylindrical flows). 
The value of ISHFTDR identifies the variable to be shifted (l-.r. 2 -</, 3-.r for Cartesian 
and ( l-.r. 2 -r. 3-0 for cylindrical) and the value of DSHIFT is the increment by which the 
sending boundary is shifted (normalized in the same manner as the mesh coordinates) to 
mate to the receiving boundary. BCINTM expects that the two sides of the interface lie 
on a common physical surface, but the grid itself may not have both sides of the interface 
in the same physical location. The most common use for this feature is a noncontiguous pe- 
riodic boundary for a single passage turbomachinery blade row solution. 1 he ISHFTDR 
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and D SHIFT variables are provided to allow the user to temporarily shift the physical 
location of the “sending 1 * blocks to the “receiving" blocks physical location. For the case 
of a noncontiguous periodic boundary in a 2-D turbine cascade, for example, ISHFTDR 
would be 2 (shift in the y direction) and the amount of the shift defined by DSHIFT would 
be the circumferential spacing of the blade rows in mesh units. The blocks are assumed 
to be contiguous in the remaining index. The M2LIM or N2LIM variables are specified 
much as they would be for a PATCH specification. The exception is that the number of 
points spanned by the limits in the direction of interpolation need not be equal. 

The search routine which determines the interpolation stencil assumes that the mating 
grid lines are piecewise linear approximations to the same curve in the interpolation direc- 
tion. A global search is performed for the proper mating cell of the first index. The closest 
cell to the point of interest is taken as the mating cell. A localized search is performed for 
the mating cells of the remaining points. The local search starts at the mating cell of the 
preceding point and searches along the mating boundary until the mating cell containing 
the new point is found. In the event that the mating cell is not found before the upper 
limit is reached in the mating block, the search continues from the lower limit in the mating 
block. This implies two things: the physical domain of the interpolation must be the same 
in the two blocks, and the domain is assumed to be periodic if the search routine goes past 
an endpoint. 

Restrictions/Limitations 


The BCINT1 boundary specification is restricted to mesh interfaces which lie on a common 
surface (no significant overlap). 

Generally, endpoints of the interpolated region in the two blocks should be coincident . 
There is at least one exception to this rule based on the above description of the search 
routine. In the case of concent ric O-grids. the endpoints of the two blocks may be misaligned 
as shown in the figure below. The interpolation routine will find the appropriate stencil for 
each point because the grids are periodic. 

The A DPA C07 COARSEN program cannot properly handle subdivision of mesh bound- 
aries involving a BCINT1 or BCINTM specification. 



.4 DP A CO 7 Boundary Data File Specifications - BCIS T 1 



The BCINT1 condition reduces to a PATCH condition if the mating blocks are actu- 
ally contiguous. However, due to the linear interpolation used in BCINT1. the scheme does 
not maintain either global or local conservation of flow variables across a non contiguous 
mesh interface. 

The BCINT1 condition also performs t he same function as the TRAF condition, but 
with fewer restrictions. The TRAF condition employs a cubic spline for interpolation, 
rather than the linear procedure used by BCINT1. and therefore. BCINT1 may be less 
accurate. 


Common Errors 


• Failure to provide 2 BCINT1 statements for each interface. 

• Incorrectly specified or misaligned extents of boundary regions (values of M1LIM1, 
M1LIM2, N1LIM1, N1LIM2, M2LIM1, M2LIM2, N2LIM1, N2LIM2 do not 
correctly define the interface extents on blocks LBLOCK1 and LBLOCR2). 

• Incorrectly specified index for the interpolation direction for LBLOCK1 or LBLOCK2. 

• Attempt to use BCINT1 for a boundary which has 2 misaligned coordinates. 

• Attempt to use BCINT1 for boundaries which are not monotonic along the interpo- 
lated index. 

• Attempt, to use COARSEN for a problem involving a BCINT1 boundary specifica- 
tion. 
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BCINTM 

BCINTM Type Noil-Contiguous Mesh Block Interface Patching 
Scheme 


Block 1 
(5x5) 






\ Block 2 

\ (9x3) 











5 














A 














1 P s ~ s: !i ! ‘ 

t • j| 















ill 



1! 












Block 4 








J A 


Block 3 
(6x4) 


(7x4) 


Non-contiguous mesh block interface involving multiple blocks 
requires a BCINTM specification (illustrated in boundary data file 
format statements below 


Application 


The BCINTM specification is used in any application involving neighboring mesh blocks 
with a non-contiguous mesh interface in one coordinate direction. The interface must be con- 
tiguous in the remaining coordinate direction. BCINTM provides a mechanism whereby 
noncontiguous boundaries involving groups of blocks may be coupled to other groups of 
blocks by interpolation along the non-contiguous index. BCINTM is a multi-block version 
of BCINT1. 

The example graphic above illustrates a two-dimensional mesh system used to predict 
the flow through a stepped duct passage. The grid was constructed with a non-contiguous 
interface between the various blocks on the top and bottom of the duct. The BCINTM 
specification is applied along either side of the interface to permit communication of flow 
variables along the interface. Here, the interpolation direction is the i coordinate direction. 
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Boundary Data File Format 

The boundary data file specifications for the mesh interface indicated in the illustrative 
graphic for the BCINTM boundary condition are given below: 

BCINTM 1 3JJPMIK 1 4 1 5 1 1 1 5 1 1 

INTDIR1 INTDIR2 - DIRECTION OF INTERPOLATION 

1 I 

ISHFTDR DSHIFT 

2 0.0 

NBLINT2 - NUMBER OF LBL0CK2 BLOCKS 
3 

NBLDAT LFACE2 LDIR2 L2LIM M2LIM1 M2LIM2 N2LIM1 N2LIM2 

3 J M 4 1 6 1 1 

4 J M 3 1 6 1 1 

5 J M 4 1 7 1 1 

NBLINT1 - NUMBER OF LBL0CK1 BLOCKS 

2 

LBLK1RR LFACE1 LDIR1 L1LIM M1LIM1 M1LIM2 N1LIM1 N1LIM2 

1 J P 1 1 5 1 1 

2 J P 1 1 9 1 1 

BCINTM 3 1JJMPIK41 15 1 1 15 1 1 

INTDIR1 INTDIR2 - DIRECTION OF INTERPOLATION 

1 I 

ISHFTDR DSHIFT 

2 0.0 

NBLINT2 - NUMBER OF LBL0CK2 BLOCKS 

2 

NBLDAT LFACE2 LDIR2 L2LIM M2LIM1 M2LIM2 N2LIM1 N2LIM2 

1 JP11511 

2 J P 1 1 9 1 1 

NBLINT1 - NUMBER OF LBL0CK1 BLOCKS 

3 

LBLK1RR LFACE1 LDIR1 L1LIM M1LIM1 M1LIM2 N1LIM1 N1LIM2 

3 J M 4 1 6 1 1 

4 JM31611 

5 JM41711 

Note that a complete BCINTM specification generally requires two BCINTM state- 
ment lines in the boundary data file. In the example above, the first specification provides 
the interblock communication for the upper blocks along the interface, while the second 
specification provides the communication for the lower blocks along the interface. It is a 
common error to underspecify a BCINTM boundary by only providing a single line per 
interface. 


Description 



80 


BCINTM - ADPAC07 Boundary Data File Specifications 


The BCINTM boundary statement provides a means for block to block communication 
for cases involving neighboring mesh boundaries which share a common surface, but are 
non-contiguous in one grid index. A proper BCINTM boundary is specified much like a 
BCINT1 boundary, except that all of the blocks involved with a particular interface are 
specified in a table on both sides of the interface. A large amount of additional data is 
required for each BCINTM specification. The sample application and specifications given 
above are designed to demonstrate the overall structure of this boundary condition. In 
the sample application, a noncontiguous mesh block interface lies between blocks 1,2 and 
blocks 3,4,5. A single pair of BCINTM specifications is all that is required to completely 
couple the mesh blocks along this interface, in spite of the fact that 5 mesh blocks are 
involved in the overall boundary definition. The key to this compact specification is that 
each BCINTM specification includes tables of data which specify which blocks lie along 
the receiving side of the interface (where the boundary data is being applied) and which 
blocks lie along the sending side of the interface (where the boundary data is derived). 
A description of the various additional specifications required for a complete BCINTM 
specification are given below. 

Immediately following the BCINTM boundary specification line is a series of multi-line 
segments which define the details of the boundary coupling. The first segment consists of I 
lines, and describes some general characteristics of the interpolation along the noncont iguous 
boundary. The second segment is the table describing the "sending'* blocks from which the 
boundary data is extracted. The third segment is a table describing the "receiving" blocks 
where the boundary data is eventually interpolated and applied. The second line in a 
BCINTM specification is a comment line, normally labeling the variables INTDIRl and 
INTDIR2. The third line defines the variables INTDIRl and INTDIR2 as either /. 

or A\ depending on the direction of interpolation for the receiving and sending blocks, 
respectively. One mesh restriction to note is that BCINTM allows only one interpolation 
direction for each side of the interface. The fourth line is a comment line normally labeling 
the variables ISHFTDR and DSHIFT. The fifth line defines the values for the variables 
ISHFTDR and DSHIFT. These variables provide a mechanism for shifting the boundary 
in one of the three coordinate directions (,?\ y % z for (’artesian flows, or .r, r. 0 for cylindrical 
flows). The value of ISHFTDR identifies the variable to be shifted (1-x. 2 ~y. 3-~ for 
Cartesian and (1-r, 2-r, 3-0 for cylindrical) and the value of DSHIFT is the increment 
by which the sending boundary is shifted (normalized in the same manner as the mesh 
coordinates) to mate to the receiving boundary. BCINTM expects that the tw T o sides of 
the interface lie on a common physical surface, but the grid itself may not have both sides 
of the interface in the same physical location. The most common use for this feature is a 
noncontiguous periodic boundary for a single passage turbomachinery blade row solution. 
The ISHFTDR and DSHIFT variables are provided to allow' the user to temporarily shift 
the physical location of the "sending" blocks to the "receiving 1 * blocks physical location. 
For the case of a noncontiguous periodic boundary in a turbine blade row solution, for 
example, ISHFTDR would be 3 (shift in the 0 direction) and the amount of the shift 
defined by DSHIFT would be the circumferential spacing of the blade rows in radians. 
The sixth line in the specification is a comment normally labeling the variable NBLINT2, 
and the seventh line specifies the number of blocks associated with the LBLOCK2 side of 
the interface (the "sending" blocks. The eigth line is again a comment normally labeling 
the variables NBLDAT. LFACE2. LDIR2. L2LIM, M2LIM1, M2LIM2. N2LIM1, 
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SI 


and N2LIM2. The next NBLINT2 lines define the table containing the limits, directions 
and faces for each of the LBLOCK2 blocks. For each block in this table. LFACE2 defines 
the coordinate face upon which the interface lies /, or A ). and LDIR2 defines the 
direction (F for plus, or M for minus) along the LFACE2 coordinate which travels away 
from the bounding surface (see Section 3.7 for more details). L2LIM defines the value 
of the LFACE2 coordinate upon which the surface is located, and M2LIM1. M2LIM2. 
and N2LIM1, and N2LIM2 define the extent of the remaining coordinates for each of 
the NBLINT2 blocks in their "natural’' order (again see Section 3.7 for more details). 
Following the table for the LBLOCK2 side of the interface, there is a commment line 
normally labeling 1 he variable NBLINT1. followed by aline specifying the number of blocks 
on the LBLOCK1 side of t lie interface. Next a comment line labeling the variables LlLIM. 
M1LIM1. M1LIM2. N1LIM1. and N1LIM2 is given. Finally, a table consisting of 
NBLINT1 lines defining the LBLOCK1 side ("receiving” blocks) information similar to 
the LBLOCK2 ("sending” blocks) table is specified. 

BCINTM creates a single interpolation stencil from all of the blocks in the LBLOCK2 
table. This stencil must be monotonic in the INTDIR2 direction. Finis, the blocks in the 
LBLOCK2 must be specified in the order they occur physically, and the limits must be 
specified so that they form a continous line. The block numbers and extents identified in 
the first line of the BCINTAI specification should match the' first entiv in each of the 
respective LBLOCK tables. 

As with BCINT1. the search routine which determines the interpolation stencil assumes 
that the mating grid lines are piecewise linear approximations to the same curve in the 
interpolation direction. A global search is performed for the proper mating cell of the first 
index. The closest cell to the point of interest is taken as the mating cell. A localized 
search is performed for the mating cells of the remaining points. I he local search staits at 
the mating cell of the preceding point and searches along the mating boundary until the 
mating cell containing the new point is found. In the event that the mating cell is not found 
before the upper limit is reached in the mating block, the search continues from the lower 
limit in the mating block. I his implies two things: the physical domain of the inteipolation 
must be the same in the two blocks, and the domain is assumed to be periodic if the search 
routine goes past an endpoint. 

R estrictions/Limitations 

The BCINTM boundary specification is rest ricted to mesh interfaces which lie on a com- 
mon surface (no significant overlap). Generally, endpoints of the interpolated region in the 
two blocks should be coincident. As with BCINT1, there is at least one exception to this 
rule based on t he above description of the search routine. In the case of concent-tic O-giids. 
the endpoints of the two blocks may be misaligned (see the BCINT1 description for de- 
tails). The interpolation routine will find the appropriate stencil for each point because the 
grids arc periodic. 

The .4 DBA C07 COARSEN program cannot properly handle subdivision of mesh bound- 
aries involving a BCINT1 or BCINTM specification. A typical fan rotor was analyzed 
using the BCINTM boundary condition at the interface between the tip clearance grid and 
the neighboring O-type grid. The figure below shows the non contiguous interface between 
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the two grid blocks, and the corresponding predicted static pressure contours. The solution 
was run in parallel on an 11 CUBE 2 computer. 

BCINTM Boundary Condition Results 

Non -Contiguous Boundary In Up Claaranca Region 




The BCINTM condition reduces to a PATCH condition if the mating blocks are 
actually contiguous. However, due to the linear interpolation used in BCINTM, the 
scheme does not maintain either global or local conservation of flow variables across a 
lion-contiguous mesh interface. 

The BCINTM condition is the only lion-contiguous patching routine for multiple 
blocks. The BCINTM condition will run in either serial or parallel ADPAC07 calcu- 
lations. 

Common Errors 


• Failure to provide 2 BCINTM statements for each interface. 

• Incorrectly specified or misaligned extents of boundary regions (values of M1LIM1, 
M1LIM2, N1LIM1, N1LIM2, M2LIM1, M2LIM2, N2LIM1, N2LIM2 do not 
correctly define the interface extents on blocks LBLOCKl and LBLOCK2). 

• Incorrectly specified index for the interpolation direction for LBLOCKl or LBLOCK2. 

• Attempt to use BCINTM for a boundary which has 2 misaligned coordinates. 

• Attempt to use BCINTM for boundaries which are not monotonic along the inter- 
polated index. 



ADPAC07 Boundary Data File Specification# - BCINTM #3 

• Incorrect, ordering of the LBLOCK2 t able of data. 

• Attempt to use BCINTM for interfaces with multiple interpolation directions on the 
same side of the interface. 

• At tempt to use BCINTM for interfaces with multiple LFACEor LDIR requirements 
in the LBLOCK1 table of data. 

• Attempt to use COARSEN for a problem involving a BCINTM boundary specifi- 
cation. 
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BCPRM 


Boundary Condition Procedure for Patched Relatively Rotating 
Mesh Blocks with Multiple Specifications 


Mesh Block #2 
(81x6x7) 



Mesh Block #1 
(81x6x7) 



Mesh Block #5 
(81x6x7) 

Mesh Block #4 
(81x6x7) 

Mesh Block #3 
(81x6x7) 


Relatively Rotating Mesh Block Interface Between 

Grids in Adjacent Blade Rows Can Employ a BCPRM Specification 

(illustrated in Boundary Data File Format 

statements below) 


Application 

The BCPRM specification is used in application involving neighboring relatively rotating 
mesh blocks, such as in rotor /stator interaction problems. 

Boundary Data File Format: 


The boundary data file specifications for the mesh interface indicated in the illustrative 
graphic for t he BCPRM boundary condition and a simple outline of the mesh topography 
are given below. Note that blocks 1 and 2 require multiple BCPRM entries in the data 
tables due to the location of the O-grid cut line. The topography below depicts a multiple 
passage 3-D O-grid system for a turbine stage. 
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BCPRM 

1 3 K 

K M M 

i j 

7 7 

1 6 1 

6 36 

46 1 

THPER 








0.41887903 







NBCPRR - 

Q 

NUMBER OF 

BLOCKS 

IN LBL0CK2 TABLE 

OF BCPRM 

SPECIFICATION 

o 

LBL0CK2B 

LFACE2B 

LDIR2B 

L2LIMB 

M2LIM1B 

M2LIM2B 

N2LIM1B 

N2LIM2B 

3 

K 

M 

7 

36 

46 

1 

6 

4 

K 

M 

7 

36 

46 

1 

6 

5 

K 

M 

7 

36 

46 

1 

6 

NRRDAT - 

NUMBER OF 

BLOCKS 

IN LBL0CK1 TABLE 

OF BCPRM 

SPECIFICATION 

4 

LBL0CK1B 

LFACE1B 

LDIR1B 

L1LIMB 

M1LIM1B 

M1LIM2B 

N1LIM1B 

N1LIM2B 

1 

K 

M 

7 

1 

6 

1 

6 

1 

K 

M 

7 

76 

81 

1 

6 

2 

K 

M 

7 

1 

6 

1 

6 

2 

K 

M 

7 

76 

81 

1 

6 

BCPRM 

3 1 K 

K M M 

: i j 

7 7 36 46 1 

6 6 

1 1 

THPER 








0.41887903 







NBCPRR - 

NUMBER OF 

BLOCKS 

IN LBL0CK2 TABLE 

OF BCPRM 

SPECIFICATION 

4 

LBL0CK2B 

LFACE2B 

LDIR2B 

L2LIMB 

M2LIM1B 

M2LIM2B 

N2LIM1B 

N2LIM2B 

1 

K 

M 

7 

6 

1 

1 

6 

1 

K 

M 

7 

81 

76 

1 

6 

2 

K 

M 

7 

6 

1 

1 

6 

2 

K 

M 

7 

81 

76 

1 

6 

NRRDAT - 

NUMBER OF 

BLOCKS 

IN LBL0CK1 TABLE 

OF BCPRM 

SPECIFICATION 

3 

LBL0CK1B 

LFACE1B 

LDIR1B 

L1LIMB 

M1LIM1B 

M1LIM2B 

N1LIM1B 

N1LIM2B 

3 

K 

M 

7 

36 

46 

1 

6 

4 

K 

M 

7 

36 

46 

1 

6 

5 

K 

M 

7 

36 

46 

1 

6 


Note that a complete BCPRM specification generally requires at least two BCPRM 
statement lines in the boundary data file. In the example above, the first specification 
provides the interblock communication for the meshes representing blade row 1 from the 
meshes representing blade row 2. and the second specification provides the communication 
for the meshes representing blade row 2 from the meshes representing blade row 1. It is 
a common error to underspecify a BCPRM boundary by only providing a single line per 
interface. 


Description: 


The BCPRM statement is an extension of the BCPRR statement to include the specifica- 
tion of multiple LBLOCK1 patches. As with BCPRR. the BCPRM statement specifies 
that a time-space interpolation utilizing data from several neighboring mesh blocks is to be 
performed to determine the boundary data for the LBLOCK1 patches. See the discussion 
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of BCPRR for details about specifying the LBLOCK2 table of data, and restrictions 
on the use of BCPRM. BCPRM differs from BCPRR only in the following way: an 
additional table of values allows multiple LBLOCKl patches to be specified. One advan- 
tage of BCPRM is clearly visible in the above example: only two boundary specifications 
are required to patch the two blade rows together, compared to seven specifications using 
BCPRR. Another, less obvious advantage is that BCPRM executes much faster than 
BCPRR in a parallel computing environment. Any BCPRM specification can be equally 
represented as a series of BCPRR specifications. The additional table of data associated 
with the LBLOCKl patches in a BCPRM statement is essentially the same as the table 
for the LBLOCK2 patches (see the description of BCPRR for additional details. A com- 
ment line is followed by a line containing the number of patches in the LBLOCKl row. 
Another comment line is followed by the specification of the limits on each LBLOCKl 
patch. One restriction on the use of BCPRM is that all of the LBLOCKl patches must 
share a common LFACE and LDIR. This requirement can be met by the use of multiple 
BCPRM or BCPRR specifications. 

It should be noted that BCPRM is limited to similarly oriented row 1 blocks. In partic- 
ular. t he face and direction of all blocks in row 1 are taken to be the same as those specified 
for LBLOCKl. BCPRR may be used in cases requiring more generality. 

BCPRM has been successfully applied to a compressor stage with H-type grids and to 
a turbine stage using O-type grids. The results were verified to be the same as if multiple 
calls to BCPRR were used. 

The significance of BCPRM is not in new capability, but in performance. Obviously, the 
benefits of BCPRM are extremely problem and machine dependent, but a small turboshaft 
compressor test case (36 blocks. I blade rows, 2,000.000 mesh points) serves as an example. 
The use of BCPRM instead of BCPRR in a fine grid calculation resulted in an estimated 
factor of 1.5 improvement in total CPU time on the LAC E cluster of workstations (without 
the ALLNODE switch). With the ALLNODE switch, the improvement was on the order 
of 20%, which is still significant. The ALLNODE switch is a special hardware device to 
enable low latency communications between IBM RS6000 workstations in a cluster. This 
means that overhead from BCPRR communications was taking at least 1/3 of the total run 
time per iteration when the ALLNODE switch was not used. This is probably a worst -case 
scenario for BCPRR because of the large number of blocks in each airfoil row. but it is 
typical of multistage compressor simulations. 


Restrictions/Limitations 


The BCPRM boundary specification is restricted to mesh int erfaces which lie on a common 
surface (no significant overlap), and have common axial and radial mesh coordinates. The 
mesh must satisfy the coordinate restrictions listed in the table above. The LBLOCKl 
table of patches must share a common face and direction as noted above. The BCPRM 
procedure is only applicable to 3-D mesh systems. 


Common Errors 
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Time dependent patch condition for multiple relatively rotating blocks 
(LBLOCK2 row values are interpolated into phantom cells of LBLOCK1 row) 


BCPRM 1 5 I I M P J K 49 1 1 31 1 31 1 31 1 31 

PERIODIC SPACING 
1.57079637 

NBCPRR - NUMBER OF BLOCKS IN ROW 2 (LBLOCK2 ROW) 

9 

NRRDAT - RELATIVELY ROTATING BLOCK NUMBERS 


5 

P 

1 

1 

31 

1 

31 


6 

P 

1 

1 

31 

1 

31 


7 

P 

1 

1 

31 

1 

31 


8 

P 

1 

1 

31 

1 

31 

' fi 

9 

P 

1 

1 

31 

1 

31 

i/ 

,r; 

10 

P 

1 

1 

31 

1 

31 

/ 

11 

P 

1 

1 

31 

1 

31 


12 

P 

1 

1 

31 

1 

31 


13 

P 

1 

1 

31 

1 

31 

/, 


NUMBL1 - NUMBER OF BLOCKS IN ROW 1 (LBLOCK1 ROW) 



4 


BLOCKS IN 

LBLOCK1 

1 BLADE 

ROW 



1 

49 

1 

31 

i 

31 

2 

49 

1 

31 

i 

31 

3 

49 

1 

31 

i 

31 

4 

A 

49 

A 

1 

A 

31 

A 

i 

A 

31 

A 

t 

block # 

T 

Him 

T 

mliml 

T 

mlim2 

t 

nliml 

t 

nlim2 


LBLOCK1 row 



BCPRM is similar to BCPRR except that multiple Row 1 blocks are specified. This 
condition is more efficient than BCPRR in parallel, and reduces the length of the 
casename.boundata file. BCPRM requires fewer interprocessor messages than 
BCPRR, but total amount of data passed is unchanged. BCPRRM is limited to 
patches involving similarly oriented Row 1 blocks. 

Figure :F7: Boundary condition BCPRM provides an alternate met hod of patching relatively 
rotating blocks in a time-dependent calculation. 
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• Failure to provide 2 BCPRM statements for each interface 

• Incorrectly specified or misaligned extents of boundary regions (values of M1LIM1, 
M1LIM2, N1LIM1, N1LIM2, M2LIM1B, M2LIM2B, N2LIM1B, N2LIM2B 
do not correctly define the interface extents on blocks LBLOCKl and LBLOCK2B) 

• Attempt to use BCPRM on a 2-D mesh block. 

• Attempt to use BCPRM at an interface between two Cartesian solution meshes. 

• Meshes do not satisfy coordinate restrictions listed above. 

• Meshes have dissimilar axial and radial coordinates at the interface. 

• Neighboring blade row 1 segments not listed in increasing theta coordinate. 

• Application of BCPRM to mesh interfaces which do not share a common surface, or 
which have excess overlap. 
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X<) 


BCPRR 


Boundary Condition Procedure for Patched Relatively Rotating 
Mesh Blocks 


Mesh Block #2 


(81x6x7) 



Mesh Block #5 
(81x6x7) 

Mesh Block #4 
(81x6x7) 

Mesh Block #3 
(81x6x7) 


Relatively Rotating Mesh Block Interface Between 

Grids in Adjacent Blade Rows Requires a BCPRR Specification 

(illustrated in Boundary Data File Format 

statements below) 


Application 


The BCPRR specification is used in application involving neighboring relatively rotating 
mesh blocks, such as in rotor/stator interaction problems. 

Boundary Data File Format: 

The boundary data file specifications for the mesh interface indicated in the illustrative 
graphic for the BCPRR boundary condition and a simple outline of the mesh topography 
are given below. Note that blocks 1 and 2 require multiple BCPRR specifications due to 
the location of the O-grid cut line. 
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BCPRR 13KKMMIJ 7 7 1 6 1 6 36 46 1 6 

THPER 

0.41887903 

NBCPRR - NUMBER OF BLOCKS IN BCPRR SPECIFICATION 
3 

LBL0CK2B LFACE2B LDIR2B L2LIMB M2LIM1B M2LIM2B N2LIM1B N2LIM2B 

3 K M 7 36 46 1 6 

4 K M 7 36 46 1 6 

5 K M 7 36 46 1 6 

BCPRR 13KKMMIJ 7 7 76 81 1 6 36 46 1 6 

THPER 

0.41887903 

NBCPRR - NUMBER OF BLOCKS IN BCPRR SPECIFICATION 
3 

LBL0CK2B LFACE2B LDIR2B L2LIMB M2LIM1B M2LIM2B N2LIM1B N2LIM2B 

3 K M 7 36 46 1 6 

4 K M 7 36 46 1 6 

5 K M 7 36 46 1 6 

BCPRR 23KKMMIJ 7 7 1 6 1 6 36 46 1 6 

THPER 

0.41887903 

NBCPRR - NUMBER OF BLOCKS IN BCPRR SPECIFICATION 
3 

LBL0CK2B LFACE2B LDIR2B L2LIMB M2LIM1B M2LIM2B N2LIM1B N2LIM2B 

3 K M 7 36 46 1 6 

4 K M 7 36 46 1 6 

5 K M 7 36 46 1 6 

BCPRR 23KKMMIJ 7 7 76 81 1 6 36 46 1 6 

THPER 

0.41887903 

NBCPRR - NUMBER OF BLOCKS IN BCPRR SPECIFICATION 

3 

LBL0CK2B LFACE2B LDIR2B L2LIMB M2LIM1B M2LIM2B N2LIM1B N2LIM2B 

3 K M 7 36 46 1 6 

4 K M 7 36 46 1 6 

5 K M 7 36 46 1 6 

BCPRR 31KKMMIJ 7 7 36 46 1 6 6 1 1 6 

THPER 

0.41887903 

NBCPRR - NUMBER OF BLOCKS IN BCPRR SPECIFICATION 

4 

LBL0CK2B LFACE2B LDIR2B L2LIMB M2LIM1B M2LIM2B N2LIM1B N2LIM2B 

1 K M 7 6 1 1 6 

1 K M 7 81 76 1 6 

2 K M 7 6 1 1 6 

2 K M 7 81 76 1 6 

BCPRR 41KKMMIJ 7 7 36 46 1 6 6 1 1 6 

THPER 
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0.41887903 









NBCPRR - 

NUMBER 

OF 

BLOCKS 

IN BCPRR 

SPECIFICATION 




4 










LBL0CK2B 

LFACE2B 

LDIR2B 

L2LIMB 

M2LIM1B 

M2LIM2B 

N2LIM1B 

N2LIM2B 

1 

K 


M 

7 
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1 
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6 

1 
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M 

7 

81 

76 
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6 

2 
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M 

7 

6 

1 
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2 
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M 

7 

81 

76 

1 


6 

BCPRR 

5 1 

K 

K M M 

I J 

7 7 36 46 1 

6 

6 

1 1 

THPER 










0.41887903 









NBCPRR - 

NUMBER 

OF 

BLOCKS 

IN BCPRR 

SPECIFICATION 




4 










LBL0CK2B 

LFACE2B 

LDIR2B 

L2LIMB 

M2LIM1B 

M2LIM2B 

N2LIM1B 

N2LIM2B 
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M 

7 

6 

1 
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1 

K 


M 

7 

81 

76 

1 


6 

2 

K 


M 

7 

6 

1 

1 


6 

2 

K 


M 

7 

81 

76 

1 


6 


Nolo that a complete BCPRR specification generally requires at least two BCPRR state- 
men! lines in the boundary data file. In the example above, the first four specifications 
provide the interblock communication for the meshes representing blade row 1 from the 
meshes representing blade row 2, and the final three specifications provide the communica- 
tion for the meshes representing blade row 2 from the meshes representing blade row 1. It 
is a common error to underspecify a BCPRR boundary by only providing a single line per 
interface. 


Description: 


The BCPRR statement specifies that a time-space interpolation utilizing data from sev- 
eral neighboring mesh blocks is to be performed to determine the boundary data for block 
LBLOCK1. This time-space interpolation provides the computational means of perform- 
ing time-dependent predictions of the flow through multiple blade row turbomachines (see 
the discussion in Section 2.2). In order to perform this type of calculation, several condi- 
tions must be satisfied. For calculations involving blade rows with dissimilar blade counts, 
it is necessary to model several blade passages per blade row. The number of blade passages 
modeled should be chosen such that the overall circumferential span of each blade row is 
identical. This implies that the blade counts should be reducible to simple integer ratios 
( 1:2. 3:4. etc.) to avoid the need for modeling an excessive number of blade passages. For 
example, in the illustrative graphic above, if we seek a solution for a single stage turboma- 
chine involving two blade rows with blade counts of 30 and 45. respectively (reduced blade 
ratio of 2:3). then the simulation would require 2 blade passages for the first blade row and 
3 passages from the second blade row. such that the overall circumferential pitch for either 
blade row is pr (the number 15 chosen as the largest common factor in the blade counts 30 
and 45). The second restriction is that the interlace separating two adjacent blade rows be 
a surface of revolution, and that meshes along this interface have common axial and radial 
grid distributions. This restriction simplifies the time-space interpolation provided by the 
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BCPRR specification. This boundary condition requires the specification of additional 
data, as shown in the format descriptor above. The variable following the label THPER 
defines the total circumferential span of the neighboring blade row's mesh representation in 
radians. For example, using the blade counts given in the previous example, the circumferen- 
tial span represented in each blade row is determined by yf , and therefore THPER should 
be 0.41X87903. The variable following the next label. NBCPRR, indicates the number of 
mesh blocks through which the time-space interpolation is to be performed. In the example 
above, if we are applying the BCPRR specification to the first blade row. then NBCPRR 
should be 3, since there are 3 mesh block surfaces in the neighboring blade row defining 
the circumferential extent of relative motion of the first blade row. The numbers immedi- 
ately following the labels LBLOCK2B. LFACE2B, LDIR2B, L2LIMB, M2LIM1B. 
M2LIM2N. N2LIM1B, and N2LIM2B represent the values of LBLOCK2, LFACE2, 
LDIR2. L2LIM, M2LIM1, M2LIM2, N2LIM1, and N2LIM2 (see the beginning of 
this section for an explanation of these variables) for each of the individual NBCPRR seg- 
ments used in the construction of the circumferential data array. The NBCPRR segments 
and their respective circumferential direction indices (either M2LIM1B. M2LIM2B or 
N2LIM1B.N2LIM2B must be listed in order of increasing theta coordinate. Due to the 
complex nature of the circumferential interpolation operator, this boundary condition is re- 
stricted to specific mesh configurations. The following chart describes the permitted mesh 
configurations for the BCPRR specification: 


BCPRR Boundary Specification Mesh Coordinate Restrictions 


LFACE1 
(Block #1 
Face) 

LFACE2 
(Block #2 
Face) 

Circumferential 

Coordinate 

Direction 

Grids Must be 
Aligned in this 
Coordinate 

I 

I or K 

K or I 

J 

J 

J only 

K 

I 

K 

I or K 

K or I 

J 


In the example described above, if block numbers 1 and 2 are the block numbers for the first 
blade row, and block numbers 3. 4, and 5 are the block numbers for the second blade row, 
then the BCPRR specification for each of the first blade row blocks would set THPER 
= 0.41887903, NBCPRR = 2, and LBLOCK2B = 3, 4, 5. In a similar manner, the 
specification for each of the blocks in the second blade row would set THPER = 0.41887903, 
NBCPRR = 4 (due to the use of the O-type mesh for each airfoil, the extent of the interface 
between the two blade rows requires 2 mesh surfaces from each of the blade row 1 airfoil 
meshes), and LBLOCK2B = 1,1, 2. 2. It should be mentioned that this specification is 
somewhat unique in that more than one block is involved in the boundary specification, 
therefore the variable LBLOCK2 is essentially ignored; however, since the blocks specified 
by the LBLOCK2B variable are assumed to be essentially duplicate representations of 
neighboring blade passages, the variables L2LIM, M2LIM1, M2LIM2, N2LIM1, and 
N2LIM2 are also ignored. The time-space interpolation is constructed to permit the 
relative rotation of blocks representing neighboring blade rows and therefore cannot be 
applied to Cartesian solution meshes. The simulation is initiated from the relative position 
of the blocks at the start of the calculation /=0. The interpolation scheme is area weighted 
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to maintain a conservative property across the interface between the relatively rotating mesh 
blocks (see the Final Report for additional details on the implementation of this boundary 
proced ure). 


Restrictioiis/Limitatioiis 


The BCPRR boundary specification is restricted to mesh interfaces which lie on a common 
surface (no significant overlap), and have common axial and radial mesh cooidinates. 1 he 
mesh must satisfy the coordinate restrictions listed in the table above. I he BCPRR 
procedure is only applicable to 3-1) mesh systems. 

Common Errors 


• Failure to provide 2 BCPRR statements for each interface 

• Incorrectly specified or misaligned extents of boundary regions (values of M1LIM1, 
M1LIM2, N1LIM1, N1LIM2, M2LIM1B, M2LIM2B, N2LIM1B, N2LIM2B 
do not correctly define the interface 1 extents on blocks LBLOCIvl and LBLOCIv2B| 

• Attempt, to use BCPRR on a 2-1) mesh block. 

• Meshes do not satisfy coordinate restrictions listed above. 

• Meshes have dissimilar axial and radial coordinates at the interface. 

• Neighboring blade row segments not listed in increasing theta coordinate. 

• Application of BCPRR to mesh interfaces which do not share a common surface, or 
which have excess overlap. 

• BCPRR runs very slowly on multiple processors - use BCPRM instead. 



94 


BDATIN - ADPAC'07 Boundary Data File Specifications 


BDATIN 

File Read 111 Mesh Interface Patching Scheme 



BDATIN/BDATOU Combination Used 
to Provide Disk Read/Write of Boundary 
Data for Interblock Communication 
Between Blocks #1 and #2 

Application 

The BDATIN specification is used to read in boundary data from an external file. This 
file may be either be created by an external program, or by the ADPAC07 boundary 
specification BDATOU. The application illustrated above indicates an application of the 
BDATIN/BDATOU combination for a two block nozzle flow case. The BDATIN/BDATOU 
combination is applied to the interface between the two mesh blocks and is equivalent to a 
PATCH specification, except that the interblock communication is accomplished through 
disk read/write rather than shared memory communication. 

Boundary Data File Format 


The boundary data file specifications for the mesh interface indicated in the illustrative 
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graphic for the BDATIN boundary condition are given below: 

BDATIN 12IIMPJK 51 1 1 31 51 1 31 51 

FILENAME 

be. 12. data 

BDATIN 21IIPMJK 151 1 31 51 1 31 51 

FILENAME 

be. 21 .data 

Note that a complete BDATIN specification requires the specification of a filename from 
which the boundary data is read. 


Description 


The BDATIN statement is utilized to provide boundary data for a mesh surface through 
external file specification. During the application of a BDATIN specification, an external 
file is opened, and phantom cell boundary data are read in for the appropriate computa- 
tional cells. The external file data may be created by an external program, or through the 
application of a BDATOU specification. A coupled set of BDATIN/BDATOU specifi- 
cations can be effectively used to replace a PATCH boundary specification. In this case, 
interblock communication would be achieved through external file read/write rather than 
shared memory. If the BDATIN/BDATOU combination is used to replace an equivalent 
PATCH condition, it should be noted that both the BDATIN and BDATOU specifica- 
tions should be written in the same manner as the PATCH statement. In other words, the 
BDATIN data is read in to the LBLOCK1 block on the mesh cells defined by L1LIM, 
M1LIM1, M1LIM2, N1LIM1 and N1LIM2. and the BDATOU data is written out 
from the LBLOCK2 block on the mesh cells defined by L2LIM, M2LIM1, M2LIM2, 
N2LIM1 and N1LIM2. The BDATIN/BDATOU routines were developed in conjunc- 
tion with early parallelization studies for the ADPAC07 to permit interblock communication 
via shared disk file read/write operations. The routines are now considered useful for cou- 
pling the ADPAC07 code with other codes capable of providing or using specified boundary 

(1 H i cl . 

A BDATIN specification requires two additional lines in addition to the normal bound- 
ary data file descriptor, as shown above. The first additional line is simply a label, while 
the second line indicates the file name relative to the current directory from which data will 
be read in for this particular boundary condition. 

Rpstrictioiis/Limitatioiis 

The BDATIN/BDATOU coupling scheme is restricted to mesh interfaces which have a 
one to one mesh point correspondancc. Other restrictions appropriate for the PATCH 
boundary condition also apply to mesh coupling using the BDATIN/BDATOU scheme. 
Data provided in the external file for the BDATIN specification must represent cell centered 
data and must be normalized consistently with the .1 DBA COT flow variable nondimension- 
alizat ion procedure. 
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Common Errors 


• Failure to provide file name for BDATIN boundary data file specification. 

• Incorrectly specified or misaligned extents of boundary regions (values of MlLIMl, 
M1LIM2, NlLIMl, N1LIM2, M2LIM1, M2LIM2, N2LIM1, N2LIM2 do not 
correctly define the interface extents on blocks LBLOCK1 and LBLOCK2). 

• BDATIN /BDATOU coupling scheme desired, but only one of the BDATIN /BDATOU 
specifications provided. 

• BDATIN /BDATOU coupling scheme boundary specification for a periodic bound- 
ary is applied to a nonperiodic mesh. 

• BDATIN/BDATOU coupling scheme boundary specification applied to a spatially 
periodic ('artesian geometry using the cylindrical coordinate solution scheme or vice 
versa (results in incorrect spatial periodicity relationships) The BDATIN/BDATOU 
coupling scheme boundary specifications for ('artesian geometries must use the ('arte- 
sian solution algorithm in ADPAC07 (see input variable FCART). 
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BDATOU 

File Write Out Mesh Interface Patching Scheme 



BDATIN/BDATOU Combination Used 
to Provide Disk Read/Write of Boundary 
Data for Interblock Communication 
Between Blocks #1 and #2 

Application 

The BDATOU specification is used to write out boundary data 1o an external file. This file 
may either be utilized by an external program, or by the ADPAC07 boundary specification 
BDATIN. The application illustrated above indicates an application of the BDATIN/BDATOU 
combination for a two block nozzle flow case. The BDATIN/BDATOU combination is 
applied to the interface between the two mesh blocks and is equivalent to a PATCH speci- 
fication. except that the interblock communication is accomplished through disk read/write 
rather than shared memory communication. 

Boundary Data Filt' Format 

The boundary data file specifications for the mesh interface indicated in the illustrative 



9S 


BDATOU - ADPAC07 Boundary Data File Specifications 


graphic for t he BDATOU boundary condition are given below: 

BDATOU 12IIMPJK 51 1 1 31 51 1 31 51 

FILENAME 

be . 12 . data 

BDATOU 2 1 I I P M J K 1 51 1 3 1 51 1 3 1 51 

FILENAME 

be . 21 . data 

Note that a complete BDATOU specification requires the specification of a filename from 
which the boundary data is read. 


Description 


The BDATOU statement is utilized to export boundary data for a mesh surface through ex- 
ternal file specification. During the application of a BDATOU specification, an external file 
is opened, and near boundary cell-centered data are written in for the appropriate computa- 
tional cells. The external file data may then be utilized by an external program, or through 
the application of a BDATIN specification, A coupled set of BDATIN/BDATOU spec- 
ifications can be effectively used to replace a PATCH boundary specification. In this case, 
interblock communication would be achieved through external file read/ write rather than 
shared memory. If the BDATIN/BDATOU combination is used to replace an equivalent 
PATCH condition, it should be noted that both the BDATIN and BDATOU specifica- 
tions should be written in the same manner as the PATCH statement. In other words, the 
BDATIN data is read in to the LBLOCK1 block on the mesh cells defined by L1LIM, 
M1LIM1, M1LIM2, NlLIMl and N1LIM2, and the BDATOU data is written out 
to the LBLOCK2 block on the mesh cells defined by L2LIM, M2LIM1, M2LIM2, 
N2LIM1 and N1LIM2. The BDATIN/BDATOU routines were developed in conjunc- 
tion with early parallelization studies for the ADPACO 7 to permit interblock communication 
via shared disk file read/write operations. The routines are now considered useful for cou- 
pling the ADPACV7 code with other codes capable of providing or using specified boundary 
data. 

A BDATOU specification requires two additional lines in addition to the normal bound- 
ary data fde descriptor, as shown above. The first additional line is simply a label, while 
the second line indicates the file name relative to the current directory to which data will 
be written out for this particular boundary condition. 


Restrictions/Limi tations 


The BDATIN/BDATOU coupling scheme is restricted to mesh interfaces which have a 
one to one mesh point correspondance. Other restrictions appropriate for the PATCH 
boundary condition also apply to mesh coupling using the BDATIN/BDATOU scheme. 
Data provided in the external file for the BDATOU specification represents near- bound ary 
cell centered data and is normalized consistently with the A DPAC07 flow variable nondi- 
mensionalization procedure. 
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Common Errors 


• Failure to provide file name for BDATOU boundary data file specification. 

• Incorrectly specified or misaligned extents of boundary regions (values of M1LIM1, 
M1LIM2, N1LIM1, N1LIM2, M2LIM1, M2LIM2, N2LIM1, N2LIM2 do not 
correct lv define the interface extents on blocks LBLOCK1 and LBLOCK2). 

• BDATIN/BDATOU coupling scheme desired, but only one of t lie BDATIN/BDATOU 
specificat ions provided. 

• BDATIN/BDATOU coupling scheme boundary specification for a periodic bound- 
ary is applied to a nonperiodic mesh. 

• BDATIN/BDATOU coupling scheme boundary specification applied to a spatially 
periodic Cartesian geometry using the cylindrical coordinate solution scheme or vice 
versa (results in incorrect spatial periodicity relationships) The BDATIN/BDATOU 
coupling scheme boundary specifications for Cartesian geometries must use the Carte- 
sian solution algorithm in A DBA (’07 ( see input variable FCART). 
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ENDDATA 


Boundary Data File Read Terminator 


Application 


The ENDDATA statement causes the ADPAC07 boundary data file read utility to dis- 
continue reading lines in the boundary data file and proceeds with normal code processing. 
Any lines following an ENDDATA statement in a boundary data file are ignored. 


Boundary Data File Format 


The boundary data file specification for an ENDDATA statement is given below: 


ENDDATA 


Note that the ENDDATA statement does not require the accompanying values of LBLOCKl, 
LBLOCK2, LFACEl. etc. as do all other boundary data file keywords. 


Description 


The ENDDATA statement is utilized to provide a terminator for the boundary data file 
read sequence in the ADPACO 7 code. Under normal operating conditions, the boundary 
data file is read in one line at a time and parsed to determine if a boundary data file 
keyword is present and uncommented on each line. When the end of the file is reached, 
the boundary data file read sequence stops, and normal processing continues as usual. In 
some cases, it may be desirable to terminate the boundary data file read sequence before 
the end of the file, and the ENDDATA statement is provided for this purpose. Whenever 
an ENDDATA statement is reached, the boundary data file read sequence is terminated, 
and all remaining lines in the boundary data file are ignored. The ENDDATA keyword is 
useful for debugging boundary condition problems, as whole portions of the boundary data 
file can be effectively eliminated by simply preceeding the section with an ENDDATA 
statement. 

Restrictions/Limitations 

The ENDDATA keyword has no restrictions. 
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Common Errors 


• Desired boundary conditions specifications following an ENDDATA statement are 
ignored. 

• A DFAC07 complains because an insufficient number of boundary condit ions were pro- 
vided for the external boundaries of each mesh block (external boundaries of some 
mesh blocks do not have a boundary condition see input keyword FBCWARN). 
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ENDTTA 


Enclwall Treatment Time- Average Mesh Block Interface Patch- 
ing Scheme 


Block #2 




Endwall Regions Between 
Discrete Treatments are 
Accounted for in ENDTTA 


Single Blade Passage 
Representation 




Discrete Endwall Treatment 
Representation (Only One 
Treatment Passage Required) 

ENDTTA Boundary Specification 
Used to Couple Blade Passage 
Fiowfield to Discrete Treatment/ 
Endwall Flow 


Application 


The ENDTTA boundary specification was developed specifically to permit numerical pre- 
diction of turbomachinery airfoil blade row flows employing endwall treatments such as 
slots, grooves, or embedded bladed passages in a time-averaged fashion. The example 
graphic above illustrates a 3-D blocked mesh system for a turbofan engine fan rotor em- 
ploying an axial slot casing treatment. The ENDTTA boundary specification employs a 
time-averaging operator (circumferential average of flow variables) between adjacent rotat- 
ing and nonrotating mesh blocks to simulate the effects of the blade row /endwall treatment 
interaction. As such, it is possible to perform steady state (representative of a time average) 
numerical analysis of turbomachinery blade passages and endwall treatments which have 
arbitrary blade passage/treatment passage count ratios. 
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Boundary Data File Format 


The boundary data file specifications for the mesh interface indicated in the illustrative 
graphic for the ENDTTA boundary condition are given below: 

ENDTTA 1 2 J J M P L L 49 1 49 81 1 33 1 33 1 17 

NTREAT RPMWALL TWALL 
113 0.0 0.0 

MBCAVG 2 1 J J P M I K 1 49 1 33 1 17 49 81 1 33 

NSEGS 
1 

BLK LFACE2 LDIR2 L2LIM M2LIM1 M2LIM2 N2LIM1 N2LIM2 
1 J M 49 49 81 1 33 

Note that a complete ENDTTA specification generally requires a companion MBCAVG 
specification to complete the blade passage mesh/treatment passage mesh interface specifi- 
cation. In the example above, the first specification provides the interblock communication 
for block 1 (the blade passage mesh) to block 2 (the treatment passage mesh) which ulti- 
mately accounts for the influence of the true end wall in the boundary specification. The 
second specification (MBCAVG) is applied to the treatment passage mesh boundary to 
simulate the time-average (circumferential average) of the neighboring blade passage mesh. 
It is a common error to underspecify an ENDTTA boundary by only providing a single 
line per interface. 


Description 


The ENDTTA boundary statement provides a. moans for block to block communication for 
the prediction of the time-averaged flow for turbomachinery blade rows employing endwall 
treatments such as discrete slots, grooves, or embedded bladed passages. This bound- 
ary condition was developed under Task (i of NASA Contract NAS3-25270 and theoretical 
details of the procedure are provided in the Final Report for Task 7 of NASA Contract 
NAS3-25270 [21]. The boundary condition is restricted to j=const.ant mesh surfaces only 
and must possess aligned coordinates in the i direction, but have misaligned mesh points 
and extents in the circumferential (k) direction. An example of an appropriate application 
of the ENDTTA specification is given in the illustrative graphic. The ENDTTA bound- 
ary specification is valid for 3-1) cylindrical solution mesh blocks only. The ENDTTA 
specification requires the specification of additional data, as shown in the format descriptor 
above. The first additional line following an ENDTTA specification is assumed to be a 
label for the variables NTREAT. RPMWALL. and TWALL. The next line contains the 
values for the variables NTREAT. RPMWALL. and TWALL. The variable NTREAT 
represents the total number of discrete treatments for the entire rotor. The analysis is nor- 
mally performed for a single rotor blade passage and a single treatment blade passage, and 
the value of NTREAT is used to effectively set the circumferential spacing between dis- 
crete treatment passages. The next variable, RPMWALL, sets the value of the rotational 
speed of the endwall regions which separate the discrete treatments. Naturally, this also 
implies the rotational speed of the treatments themselves, and the value of RPMWALL 
in this context must be consistent with the value of RPM specified in the input file for the 
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treatment passage mesh block* The third variable, TWALL. sets the thermal boundary 
condition for the wall segments separating the discrete treatment passages, and is specified 
in the same manner as the TWALL variable described for the SSVI (viscous solid wall) 
boundary condition. 


Restrictioiis/Limitatioiis 


The ENDTTA boundary specification is restricted to mesh interfaces which lie on a com- 
mon surface (no significant overlap). The ENDTTA procedure permits only that the k 
coordinates between adjacent mesh surfaces are misaligned. The ENDTTA procedure is 
only valid if applied to j= const ant mesh surfaces. ENDTTA will not run across multiple 
processors in a parallel computing environment. 


Common Errors 


• Failure to provide a coupled pair of ENDTTA and MBCAVG statements for each 
interface. 

• Failure to properly specify the values for RPM, TWALL and/or NTREAT 

• Incorrectly specified or misaligned extents of boundary regions (values of M1LIM1, 
M1LIM2, N1LIM1, N1LIM2, M2LIM1, M2LIM2, N2LIM1, N2LIM2 do not 
correctly define the interface extents on blocks LBLOCK1 and LBLOCK2). 

• Attempt to use ENDTTA for an / or k constant boundary. 

• Attempt to use ENDTTA for a Cartesian solution mesh. 

• Attempt to use ENDTTA for a boundary which has 2 misaligned coordinates. 

• Attempt to use ENDTTA with multiple processors. 
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EXT2DG 

Generic 2-D Outflow Boundary Condition 


Flow 



2-D Mesh Block #2 
(28x9x1) 



Duct Exit with Uniform 
Static Pressure Requires an 
EXT2DG Specification 


2-D Mesh Block #1 
(28x23x1) 


Application 

The EXT2DG specification is used to impose a generic subsonic outflow boundary condi- 
tion with a uniform exit static pressure for 2-1) mesh blocks. The example graphic above 
illustrates a 2-1) 2-block mesh system mixing two adjacent streams of varying properties. 
In this case, the EXT2DG boundary specification is used to set the outflow boundary flow 
properties by specifying a uniform exit static pressure. This boundary condition has been 
utilized extensively as an exit flow specifier for 2-D duct flows. 

Boundary Data File Format 

The boundary data file specifications for the exit flow mesh surfaces indicated in the illus- 
trative graphic for the EXT2DG boundary condition are given below: 
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EXT2DG 1 1 I I M M J K 28 28 1 23 1 2 1 23 1 2 

PEXIT 

0.625 

or the alternate specification: 

EXT2DG 1 1 I I M M J K 28 28 1 23 1 2 1 23 1 2 

PEXIT EMDOT PRELAX 

0.625 11.4 0.1 

Note that a complete EXT2DG specification requires two additional lines following the 
EXT2DG boundary data file specification line. Failure to properly specify the data in 
these additional lines is a common EXT2DG specification error. 


Description 


The EXT2DG statement specifies that a generic, subsonic, uniform static pressure exit 
flow boundary condition is to be applied to the mesh surface specified by LFACEl on 
the 2-D mesh block specified by LBLOCK1. The EXT2DG boundary condition should 
be applied for those cases where any other “specialized" exit boundary condition (such as 
EXT2DT, EXT2DP, etc.) does not apply. The EXT2DG boundary condition is also 
likely to be somewhat more efficient computationally than the other exit boundary condi- 
tion procedures, at the expense of some physical simplification. The EXT2DG procedure 
utilizes a Riemann invariant formulation to compute exit velocities based on a specified 
constant exit static pressure. Included in the EXT2DG procedure is a special correction 
scheme which forces the flow to pass out of the flow domain at the boundary. In other words, 
if the computed velocities result in a local inflow at the EXT2DG boundary, no matter 
how small the magnitude of the inflow, the velocities are reset to zero at that point. This 
boundary condition requires the specification of additional data, as shown in the boundary 
data format descriptor above. The first additional line following the EXT2DG specifica- 
tion is assumed to be a label and may contain any information; however, for consistency it 
is recommended that the label PEXIT be used. The next line contains the value imposed 
for the variables PEXIT which represents the downstream exit static pressure ratio used 
in the EXT2DG characteristic solution sequence. The value of the PEXIT variable is the 
desired normalized downstream static pressure computed as: 


PEXIT 


static,dtsii'?d 


Prrf 


where the variable P rc j is specified by the input variable PREF. It should be mentioned 
that for most geometries, the value of PEXIT, in combination with any inlet flow boundary 
conditions, will normally govern the resulting solution mass flow rate (exceptions to this 
rule will occur when the inlet mass flow rate boundary condition procedure INLETM is 
applied). Values of PEXIT <0.0 are not permitted. As the value of PEXIT is reduced, 
the flow through the boundary will ultimately choke, and further reductions of PEXIT 
will no longer increase the mass flow through the boundary. Naturally, poor convergence or 
solution divergence can occur if PEXIT is too high or too low when compared to the rest 
of the flow domain. In such cases where this occurs, it is recommended that the solution be 
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started with more conservative boundary values, and t hen restarted using t lie final boundary 
values. 

An alternate specification is provided for the EXT2DG boundary specification as shown 
in the sample application above. In this case, three values are included following the original 
boundarv specification line. The alternate specification is provided as a means of achieving 
a desired mass flow rate through the bounding surface using the EXT2DG algorithm. 
The desired mass flow rate is achieved iteratively by incrementally adjusting the exit static 
pressure specification until the desired flow rate is achieved. Therefore, in this specification, 
the variable PEXIT described in detail above is the initial exit static pressure used in the 
iterative process. EMDOT represents the desired mass flow rate through the bounding 
surface in pounds mass, and PRELA.X is a relaxation factor to stabilize the Relative 
process (values may range from 0.0 to 1.0, though poor convergence is likely for values 
larger than 0.1 ). For Cartesian flow calculations a unit depth ( 1.0 in mesh coordinates) is 
assumed for the third coordinate direction to determine the mass flow rate. For cylindrical 
flow calculations, the geometry is assumed to be axisymmetric and a multiple of 'lit is used 
in the mass flow integration (the mass flow is computed as if the full circumference ol the 
axisymmetric geometry were employed). This procedure is not foolproof, and suffers from 
the fact that when a job is restarted, if an updated exit pressure is not inserted in the 
boundary data file, then the pressure-mass flow iterative process will essentially start over. 
The ADPAC07 code will automatically determine when to employ the iterative process In- 
identifying the additional boundary specification variables. 


Rostrictioiis/Liinitatioiis 


Common Errors 


• Failure to specify the additional data value PEXIT. 

• Improper specification of the alternate (mass flow) iterative scheme. 

• Reduct ions in the value of PEXIT do not increase the mass flow rate because of flow 
choking. 

• Value of PEXIT is too high (flow cannot get started). 
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EXITG 

Generic Outflow Boundary Condition 


Mesh Block #1 
(49x33x33) 



Flow 



Application 


The EXITG specification is used to impose a generic subsonic outflow boundary condition 
with a uniform exit static pressure. The example graphic above depicts a simple duct flow 
using a Cartesian-based H-grid, where the exit boundary plane is controlled by an EXITG 
specification. This boundary condition has been utilized extensively as an exit flow specifier 
for duct flows. 

Boundary Data File Format 


The boundary data file specification for the mesh surface indicated in the illustrative graphic 
for the EXITG boundary condition is given below: 

EXITG 1 1 I I M M J K 49 49 1 33 1 33 1 33 1 33 

PEXIT 

0.625 


or the alternate specification: 
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EXITG 1 1 I I M M J K 49 49 1 33 1 33 1 33 1 33 

PEXIT EMDOT PRELAX 

0.625 40.0 0.001 

Note that a complete EXITG specification requires two additional lines following the EX- 
ITG boundary data file specification line. Failure to properly specify the data in these 
additional lines is a common EXITG specification error. 


Description 


The EXITG statement specifies that a generic, subsonic, uniform static pressure exit flow 
boundary condition is to be applied to the mesh surface specified by LFACEl on the block 
specified by LBLOCKl. The EXITG boundary condition should be applied for those 
cases where any other "specialized” exit boundary condition (such as EXITT, EXITP. 
etc.) does not apply. The EXITG boundary condition is also likely to be somewhat more 
efficient computationally than the other exit boundary condition procedures, at the expense 
of some physical simplification. EXITG may be used on any mesh face (I. .1. or K constant) 
for either cylindrical or ( artesian-based solution schemes (see the input variable FCART). 
The EXITG procedure util izes a Reimann invariant formulation to compute exit velocities 
based on a specified constant exit static pressure. Included in the EXITG procedure is 
a special correction scheme which forces the flow to pass out of the flow domain at the 
boundary. In other words, if the computed velocities result in a local inflow at the EXITG 
boundary, no matter how small the magnitude of the inflow, the velocities are reset to zero 
at that point. This boundary condition requires the specification of additional data, as 
shown in the Boundary Data Format descriptor above. The first additional line follow- 
ing the EXITG specification is assumed to be a label and may contain any information: 
however, for consistency it is recommended that the label PEXIT be used. I he next line 
contains the value imposed for the variables PEXIT which represents the downstream exit 
static pressure ratio used in the EXITG characteristic solution sequence. The value of the 
PEXIT variable is the desired normalized downstream static pressure computed as: 


PEXIT 


I stnticAf sirftt 

KT f 


where the variable P rf j is specified by the input variable PREF. It should be mentioned 
that for most geometries, the value of PEXIT. in combination with any inlet flow boundary 
conditions, will normally govern the resulting solution mass flow rate (exceptions to this 
rule will occur when the inlet mass flow rate boundary condition procedure INLETM is 
applied). Values of PEXIT <().() are not permitted. As the value of EXITP is reduced, 
the flow through the boundary will ultimately choke, and further reductions of EXITP 
will no longer increase the mass flow through the boundary. Naturally, poor convergence or 
solution divergence can occur if PEXIT is too high or too low when compared to the rest 
of the flow domain. In such cases where this occurs, it is recommended that the solution be 
started with more conservative boundary values, and then restarted using the final boundary 


values. 


An alternate specification is provided for the EXITG boundary specification as shown 
in the sample application above. In this case, three values are included following the original 
boundary specification line. The alternate specification is provided as a means of achieving 
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a desired mass flow rate through the hounding surface using the EXITG algorithm. The 
desired mass flow rate is achieved iteratively by incrementally adjusting the exit static 
pressure specification until the desired flow rate is achieved. Therefore, in this specification, 
the variable PEXIT described in detail above is the initial exit static pressure used in the 
iterative process. EMDOT represents the desired mass flow rate through the bounding 
surface in pounds mass, and PRELAX is a relaxation factor to stabilize the iterative 
process (values may range from 0.0 to 1.0, though poor convergence is likely for values 
larger than 0.1). This procedure is not foolproof, and suffers from the fact that when a 
job is restarted, if an updated exit pressure is not inserted in the boundary data file, then 
the pressure-mass flow iterative process will essentially start over. The ADPAC07 code will 
automatically determine when to employ the iterative process by identifying the additional 
boundary specification variables. 


Restrictions/Limit ations 


The EXITG boundary specification is not restricted to fl-D mesh surfaces (although for 
consistency 2-D mesh surfaces may use the EXT2DG boundary specification). 


Common Errors 


• Failure to specify the additional data value PEXIT. 

• Improper specification of the alternate (mass flow) boundary scheme. 

• Reductions in the value of PEXIT do not increase the mass flow rate because of flow 
choking. 

• Value of PEXIT is too high (flow cannot get started). 
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EXT2DP 


2-D Patched Tuibomaoliineiy Exit Boundaiy Condition 


2-D Mesh Block #1 
(65x9x1) | 


2-D Mesh Block #2 
(65x9x1) | 


2-D Mesh Block #3 
(49x9x1) | 


2-D Mesh Block #4 
(49x9x1) | 



Static 

Pressure 


Circumferential 
Flow Angle 


Patched Exit Static Pressure and Radial 
Equilibrium for 2-D Turbomachinery Exit Flow 
Requires an EXT2DP Specification 
(illustrated in Boundary Data File Format 
statements below) 


Static pressure specified at either 
lower or upper y boundary 
Radial equilibrium equation integrated to 
complete exit static pressure specification 


Application 

The EXT2DP specification is used to impose a. turbomachinery-based exit boundary con- 
dition based on radial equilibrium for 2-1) mesh systems employing multiple blocks radially 
across the exit plane. The example graphic above illustrates a four block mesh system used 
to predict the axisymmtric flow through a. high bypass ratio 1 urbofan engine geometry. The 
solution utilizes a specified freest ream static pressure at the outer boundary of block 4. and 
a] ) EXT2DT specification to integrate the radial equilibrium equation equation inward 
radially along the out flow boundary. In order to continue the radial equilibrium integration 
process across the block boundary between blocks 3 and 4. an EXT2DP specification is 
used to patch the two blocks. This boundary condition has been utilized extensively in 
conjunction with the EXT2DT specification as an exit flow specifier for both ducted and 
unducted turbomachinery flows. 
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Boundary Data File Format 


The boundary data file specification for the 2-D mesh surface indicated in the illustrative 
graphic for the EXT2DP boundary condition is given below: 

EXT2DP 43 1 IMMLH 49 49 1 91 2 991 2 

Note that the M2LIM1, M2LIM2 variables in the EXT2DP specification define a single 
j mesh line in mesh block LBLOCK2. Failure to properly regard this requirement is a 
common EXT2DP specification error. It should also be mentioned that EXT2DP also 
requires proper specification of the LSPECl variable for proper execution. 


Description 


The EXT2DP keyword specifies that a turbomachinery- based radial equilibrium patched 
exit flow boundary condition is to be applied to the mesh surface specified by LFACE1 on 
t he 2-D block specified by LBLOCKl. The EXT2DP boundary condition was specifically 
designed as an exit flow boundary procedure for axial and mixed flow turbomachinery 
geometries employing multiple, stacked 2-D mesh blocks (radially) at an exit boundary 
plane. The EXT2DP boundary condition procedure utilizes a combination static pressure 
specification and integration of t he radial equilibrium equation to define the static pressure 
field at all points on the boundary surface. The initial static pressure specification used 
to initiate the radial equilibrium integration process is obtained from a neighboring mesh 
block. As a result of the complexity of this procedure, several mesh restrictions were 
imposed to simplify the application of this approach. The primary assumption is that the 
integration of the radial equilibrium equation may be performed along the j coordinate 
direction of the mesh. Hence, the j coordinate should be the radial-like direction. A single 
specification of static pressure is required at either the maximum or minimum extreme of 
the j coordinate of the boundary surface in order to initiate the integration process. The 
direction of integration, and location of application of the specified exit static pressure 
are determined by the LSPECl variable in the calling sequence. If LSPECl = L, for 
LOW. then PEXIT is applied to the lower (smallest value) of the j index, and the radial 
equilibrium equation is integrated outward (increasing j direction). If LSPECl — H, 
for HIGH, then PEXIT is applied to the upper (largest value) of the j index, and the 
radial equilibrium equation is integrated inward (decreasing j direction). The direction of 
integration implied by LSPECl must be consistent with the location of the neighboring 
mesh block (LBLOCK2) from which the initial pressure data is derived. The j coordinate 
location from which the pressure is taken in mesh block LBLOCK2 is determined by the 
M2LIM1, M2LIM1 variable, and the specification of the LSPEC2 control parameter. 
If the M2LIMl,M2LIM2 combination is taken from the higher j index, then LSPEC2 
should be H. If the M2LIMl,M2LIM2 combination is taken from the lower j index, then 
LSPEC2 should be L. Under most circumstances, the static pressure is taken from either 
the uppermost or lowermost j coordinate, in which case LSPEC2 should be either H or 
L, respectively. The remaining flow variables on the EXT2DP boundary are updated by 
a Reimann invariant formulation based on the resulting local static pressure field. Included 
in the EXT2DP procedure is a special correction scheme which forces the flow to pass out 
of the flow domain. In other words, if the computed velocities result in a local inflow at the 
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EXT2DP boundary, no matter how small the magnitude of the inflow, the velocities are 
reset to zero at that point. 

Restrictions /Limitations 


The EXT2DP boundary condition assumes that the mesh is oriented in such a. fashion that 
the radial coordinate is defined as r = \J y 1 + z 2 , For axial flow turbomachinery, this implies 
that the axis of rotation (or the centerline) coincides with the x axis. It is also required 
that the radial like direction of the mesh be defined by the j coordinate, and is therefore 
not valid on a j =constant mesh plane. This is required in order to properly integrate the 
radial equilibrium equation to complete the exit static pressure specification. Examples of 
this type of mesh system can be found in the chapter defining standard configurations. The 
EXT2DP boundary specification is restricted to 2-1) mesh surfaces (3-1) mesh surfaces 
should use the EXITP boundary specification). By default, it is important that this type 
of boundary condition be carefully specified and the final solution carefully examined to 
ensure that the desired mesh patching be adequately satisfied. It is a common error to 
patch to the wrong grid, or the wrong end of the correct grid, and still obtain a converged 
sol lit ion. 


Common Errors 


• Application of EXT2DP to a 3-D mesh system. 

• Failure to properly specify the LSPECl. LSPEC2 variables. 

• M2LIM1 and M2LIM2 differ. 

• Radial-like direction of the mesh is not the y' coordinate. 

• Failure to properly specify the LSPECl variable on the boundary data file specifica- 
tion line. 

• EXT2DP specification patched to the wrong grid. 

• EXT2DP specification patched to the wrong end of the correct grid. 

• EXT2DP boundary condition used but no EXT2DT or EXITT boundary condition 
specified. 

• EXT2DP boundary condition called before EXT2DT (not required, but could cause 
problems). 
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EXITP 


Patched Turbomachinery Exit Boundary Condition 


Mesh Block #2 



Application 

The EXITP specification is used to impose a turbomachinerv-based exit boundary condi- 
tion based on radial equilibrium for mesh systems employing multiple blocks radially across 
the exit plane. The example graphic illustrates a two block 3-1) mesh system used to predict 
the flow through a blade passage of a turbomachinery fan rotor with a part span shroud. 
The blocks are divided radially by the part span shroud, and as a result, the exit boundary 
plane consists of t wo mesh boundary segments. In order to employ a t urbomachinerv-based 
radial equilibrium exit flow boundary condition for this case, the EXITT specification is 
applied to the inner mesh block (#1) and the EXITP boundary condition is used for the 
outer block (#2) to complete the inner to outer integration of the radial equilibrium equa- 
tion across the mesh block interface. This boundary condition has been utilized extensively 
in conjunction with the EXITT specification as an exit flow specifier for both ducted and 
unducted turbomachinery flows. 


Boundary Data File Format 


The boundary data file specification for the mesh surface indicated in the illustrative graphic 
for the EXITP boundary condition is given below: 
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EXITP 2 II I M M L H 73 73 1 21 1 25 13 13 1 25 


Note that the M2LIM1, M2LIM2 variables in the EXITP specification define a single 
j mesh line in mesh block LBLOCK2. Failure to properly regard this requirement, is a 
common EXITP specification error. It should also be mentioned that EXITP also requires 
proper specification of the LSPEC1 variable for proper execution. 


Description 


The EXITP key word specifies that a turbomachinery-based radial equilibrium patched exit 
flow boundary condition is to be applied to the mesh surface specified by LFACE1 on the 
block specified by LBLOCK1. The EXITP boundary condition was specifically designed 
as an exit flow boundary procedure for axial and mixed flow turbomachinery geometries 
employing multiple, stacked mesh blocks (radially) at an exit boundary plane. The EX- 
ITP boundary condition procedure utilizes a combination static pressure specification and 
integration of the radial equilibrium equation to define the static pressure field at all points 
on the boundary surface. The initial static pressure specification used to initiate the radial 
equilibrium integration process is obtained from a neighboring mesh block. As a result of 
the complexity of this procedure, several mesh restrictions were imposed to simplify the 
application of this approach. The primary assumption is that the integration of the radial 
equilibrium equation may be performed along t he j coordinate direction of the mesh. Hence, 
the j coordinate should be the radial-like direction. A single specification of static pressure 
is required at either the maximum or minimum extreme of the J coordinate of the bound- 
ary surface in order to initiate the integration process. The direction of integration, and 
location of application of the specified exit static pressure are determined by t he LSPECl 
variable in the calling sequence. If LSPECl = L, for LOW, then PEXIT is applied to 
the lower (smallest value) of the j index, and the radial equilibrium equation is integrated 
outward (increasing j direction). If LSPECl = II. for HICH. then PEXIT is applied to 
the upper (largest value) of the j index, and the radial equilibrium equation is integrated 
inward (decreasing j direction). The direction of integration implied by LSPECl must be 
consistent with the location of the neighboring mesh block (LBLOCK2) from which the 
initial pressure data is derived. The j coordinate location from which the pressure is taken 
in mesh block LBLOCK2 is determined by the M2LIM1, M2LIM1 variable, and the 
specification of the LSPEC2 control parameter. If the M2LIM1,M2LIM2 combination 
is taken from the higher j index, then LSPEC2 should be H. If the M2LIM1 ,M2LIM2 
combination is taken from the lower j index, then LSPEC2 should be L. Under most 
circumstances, the static pressure is taken from either the uppermost or lowermosl j coor- 
dinate 1 , in which case LSPEC2 should be either H or L, respectively. The remaining flow 
variables on the EXITP boundary are updated by a Reimann invariant formulation based 
on the resulting local static pressure field. Included in the EXITP procedure is a special 
correction scheme which forces the flow to pass out of the flow domain. In other words, if 
the computed velocities result in a local inflow at the EXITP boundary, no matter how 
small the magnitude of the inflow, the velocities are reset to zero at that point. 


Restrictions/Limitations 
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The EXITP boundary condition assumes that the mesh is oriented in such a fashion that 
the radial coordinate is defined as r = y/y 2 + s*. For axial flow turbomachinery, this implies 
that the axis of rotation (or the centerline) coincides with the .r axis. It is also required 
that the radial-like direction of the mesh be defined by the j coordinate, and is therefore 
not valid on a j ^constant mesh plane. This is required in order to properly integrate the 
radial equilibrium equation to complete the exit static pressure specification. Examples 
of this type of mesh system can be found in the chapter defining standard configurations. 
The EXITP boundary specification is restricted to 3-1) mesh surfaces (2-1) mesh surfaces 
should use the EXT2DP boundary specification). 


Common Errors 


• Application of EXITP to a *2-1) mesh system. 

• Failure to properly specify the LSPEC2 variable. 

• M2LIM1 and M2LIM2 differ. 

• Radial-like direction of the mesh is not the j coordinate. 

• Failure to properly specify the LSPEC1 variable on the boundary data file specifica- 
tion line. 
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EXT2DT 


*2-D Turbomacliinerv Exit Boundary Condition 


2-D Mesh Block #1 
(49x17x1) 



j 



Pressure Flow Angle 

Static pressure specified at either 
lower or upper 7' boundary 
Radial equilibrium equation integrated to 
complete exit static pressure specification 

Specified Exit Static Pressure and Radial 
Equilibrium for 2-D Turbomachinery Exit Flow 
Requires an EXT2DT Specification 
(illustrated in Boundary Data File Format 
statements below) 


Application 


The EXT2DT specification is used to impose a turbomachinery-based exit boundary con- 
dition based on radial equilibrium for 2-D mesh blocks. The example graphic illustrated 
above depicts an EXT2DT specification for a 2-D (axisynnnetric) flow solution for a tur- 
bomachinery blade row. This boundary condition lias been utilized extensively as an exit 
flow specifier for both ducted and unducted 2-D turbomacliinerv flows. 


Boundary Data File Format 


The boundary data file specification for the mesh surface indicated in the illustrative graphic 
for the EXT2DT boundary condition is given below: 

EXT2DT 1 II IMMLL 49 49 1 17 1 21 17 1 2 

PEXIT 

1.105 

or the alternate specification: 

EXT2DT 1 1 I IMMLL 49 49 1 17 1 21 17 1 2 
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PEXIT EMDOT PRELAX 

1.105 13.7 0.001 

Note that a complete EXT2DT specification requires two additional lines following the 
EXT2DT boundary data file specification line. Failure to properly specify the data in these 
additional lines is a common EXT2DT specification error. It should also be mentioned that 
EXT2DT also requires proper specification of the LSPEC1 variable for proper execution. 


Description 


The EXT2DT keyword specifies that a turbomachinery-based radial equilibrium exit flow 
boundary condition is to be applied to the mesh surface specified by LFACE1 on the 2-1) 
mesh block specified by LBLOCK1. The EXT2DT boundary condition was specifically 
designed as an exit flow boundary procedure for 2-1) axial and mixed flow turbomachinery 
geometries. Pure radial flow turbomachinery exit flow boundaries may usually be specified 
by the EXT2DG boundary condition. Due to the form of the radial equilibrium equation 
utilized in the EXT2DG routine, only cylindrical coordinate solution meshes are permit ted 
to use this routine. The EXT2DT boundary condition procedure utilizes a combination 
static pressure specification and integration of the radial equilibrium equation to define the 
static pressure field at all points on the boundary surface. As a result of the complexity of 
this procedure, several mesh restrictions were imposed to simplify the application of this 
approach. The primary assumption is that the integration of the radial equilibrium equation 
may be performed along the j coordinate direction of the mesh. Hence, the j coordinate 
should be the radial-like direction. A single specification of static pressure is required at 
either the maximum or minimum extreme of the j coordinate of the boundary surface in 
order to initiate the integration process. The direction of integration, and location of appli- 
cation of the specified exit static pressure are determined by the LSPEC1 variable in the 
calling sequence. If LSPECl = L. for LOW, then PEXIT is applied to the lower (smallest 
value) of the j index, and the radial equilibrium equation is integrated outward (increasing 
j direction). If LSPECl = H, for HIGH, then PEXIT is applied to the upper (largest 
value) of the j index, and the radial equilibrium equation is integrated inward (decreasing 
j direction). The remaining flow variables on the EXT2DT boundary are updated by a 
Reimann invariant formulation based on the resulting local static pressure field. Included 
in the EXT2DT procedure is a special correction scheme which forces the flow to pass out 
of the flow domain. In other words, if the computed velocities result in a local inflow at 
the EXT2DT boundary, no matter how small the magnitude of the inflow, the velocities 
are reset to zero at that point. This boundary condition requires the specification of addi- 
tional data, as shown in the boundary data format descriptor above. The first additional 
line following the EXT2DT specification is assumed to be a label and may contain any 
information: however, for consistency it is recommended that the label PEXIT be used. 
The line following the PEXIT label contains the value of specified nondimensional exit 
static pressure used to initiate the radial equilibrium integration procedure. The value of 
the PEXIT variable is computed as follows: 

/> V* t t * F t jritstatic,de sired 

FExn = — — 

1 ref 

The variable F rf j is specified by the input variable PREF. Values of PEXIT <0.0 are 
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not permitted. Naturally, poor convergence or solution divergence can occur if the value of 
PEXIT suggests boundary data which are significantly different from the remainder of the 
flowfield. In such cases where this occurs, it is recommended that the solution be started 
with more conservat ive boundary values, and then restarted using t he final boundary values. 

An alternate specification is provided for the EXDT2DT boundary specification as 
shown in the sample application above. In this case, three values are included following 
the original boundary specification line. The alternate specification is provided as a means 
of achieving a desired mass flow rate through the bounding surface using the EXT2DT 
algorithm. The desired mass flow rate is achieved iteratively by incrementally adjusting 
the exit static pressure specification until the desired flow rate is achieved. 1 lierefore. in 
this specification, the variable PEXIT described in detail above is the initial exit static- 
pressure used in the iterative process. EMDOT represents the desired mass flow rate 
through the bounding surface in pounds mass, and PRELAX is a relaxation factor to 
stabilize the iterative process (values may range from 0.0 to 1.0. though poor convergence 
is likely for values larger than 0.1). For ('artesian flow calculations a unit depth (1.0 in 
mesh coordinates) is assumed for the third coordinate direction to determine the mass flow 
rate. For cylindrical flow calculations, the geometry is assumed to be axisymmetric and 
a multiple of 2tt is used in the mass flow integration (the mass flow is computed as if the 
full circumference of the axisymmetric geometry were employed). This procedure is not 
foolproof, and suffers from the fact that when a job is restarted, il an updated exit piessute 
is not inserted in the boundary data file, then the pressure-mass How iterative process will 
essentially start over. The ADBAC07 code will automatically determine when to employ 
the iterative process by identifying the additional boundary spot ification \aiiables. 


R estrictious /Limitations 


The EXT2DT boundary condition assumes that the mesh is oriented in such a fashion that 
t he radial coordinate is defined as r = \fp + ~ 2 . For axial flow turbomachinery, t his implies 
that the axis of rotation (or the centerline) coincides with the r axis. It is also required 
that the radial-like direction of the mesh Ire defined by the j coordinate, and is therefore 
not valid on a j -constant mesh plane. This is required in order to properly integrate the 
radial equilibrium equation to complete the exit static pressure specification. Examples of 
this type of mesh system can be found in the chapter defining standard configurations. The 
EXT2DT boundary specification is restricted to 2-1) mesh surfaces (3-D mesh surfaces 
should use the EXITT boundary specification). 

Common Errors 


• Application of EXT2DT to a 3-D mesh system. 

• Failure to specify the additional data value PEXIT. 

• Improper specification of the alternate (mass flow) iterative scheme. 

• Radial-like direction of the mesh is not the j coordinate. 
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• Cylindrical solution procedure not selected (FCART=1.0) 

• Failure to properly specify the LSPEC1 variable on the boundary data file specifica- 
tion line. 

• Value of PEXIT is too high (flow cannot get started). 
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EXITN 


Non-Reflecting Outflow Boundary Condition 


Mesh Block #1 
(49x33x33) 



Flow 



Application 


The EXITN specification is used to impose a non-reflecting outflow boundary condition 
for time-dependent flow calculations where spuroius numerical reflections normally imposed 
by other boundary procedures are undesirable. The example graphic above depicts a simple 
duct flow using a Cartesian-based H-grid, where the exit boundary plane is controlled by 
an EXITN specification. This boundary condition should be used for time-dependent flow 
calculations only. 

Boundary Data File Format 


The boundary data file specification for the mesh surface indicated in the illustrative graphic 
for the EXITN boundary condition is given below: 

EXITN 1 1 I I M M J K 49 49 1 33 1 33 1 33 1 33 


Description 
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The EXITN statement specifies that a non -relec ting exit flow boundary condition is to be 
applied to the mesh surface specified by LFACE1 on the block specified by LBLOCK1. 
The EXITN boundary condition should be used for time-dependent flow calculations where 
spurious numerical reflections which normally occur for other exit boundary conditions (such 
as EXITT, EXITP. etc.) are undesirable. EXITN may be used on any mesh face (I. J, or 
K constant) for either cylindrical or Cartesian-based solution schemes (see the input variable 
FCART). The EXITN procedure utilizes a charact.eristic-ba.sed formulation described in 
the A DP AC 07 final report [21]. 

Restrictions /Limitations 


The EXITN boundary specification should only be applied for time-dependent flow cal- 
culations. Steady state problems can usually use the EXT2DG, EXITX. or EXITT 
boundary specification ). 

Common Errors 


• Application of EXITN for a steady state solution. 
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EXITT 

Turbomaoliineiy Exit Bounclary Condition 


Mesh Block #1 
(49x17x17) 






Static pressure specified at either lower 
or upper '3'' boundary 

Radial equilibrium equation integrated 
to complete exit static pressure specification 

m 

Specified Exit Static Pressure and Radial 
Equilibrium for Turbomachinery Exit Flow 
Requires an EXITT Specification 
(illustrated in Boundary Data File Format 
statements below) 


Application 

The EXITT specification is used to impose a turbomachinery-based exit boundary condi- 
tion based on radial equilibrium. The illustrative graphic above depicts an application of 
the EXITT outflow boundary condition for an 11-type mesh for a. turbomachinery fan rotor 
blade passage. The EXITT specification provides the radial variation of flow properties 
at the outflow boundary resulting from the application of a simplified form of the radial 
equilibrium equation. This boundary condition has been utilized extensively as an exit flow- 
specifier for both ducted and unducted turbomachinery flows. 

Boundary Data File Format 

The boundary data file specification for the mesh surface indicated in the illustrative graphic 
for the EXITT boundary condition is given below: 

EXITT 1 1 I I M M L L 49 49 1 17 1 17 1 17 1 17 

PEXIT 

1.105 

or the alternate specification: 
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EXITT 1 II I M M L L 49 49 1 17 1 17 1 17 1 17 

PEXIT EMDOT PRELAX 

1.105 13.7 0.001 

Note that a complete EXITT specification requires two additional lines following the 
EXITT boundary data file specification line. Failure to properly specify the data in these 
additional lines is a common EXITT specification error. It should also be mentioned that 
EXITT also requires proper specification of the LSPEC1 variable for proper execution. 


Description 


The EXITT keyword specifies that a turbomachinery- based radial equilibrium exit flow 
boundary condition is to be applied to the mesh surface specified by LFACE1 on the block 
specified by LBLOCK1. The EXITT boundary condition was specifically designed as an 
exit flow boundary procedure for axial and mixed flow turbomachinery geometries (pure 
radial flow turbomachinery exit flow boundaries may be usually be specified by the EXITG 
boundary condition). The EXITT boundary condition procedure utilizes a combination 
static pressure specification and integration of t he radial equilibrium equation to define the 
static pressure field at all points on the boundary surface. As a result of the complexity of 
this procedure, several mesh restrictions were imposed to simplify the application of this 
approach. The primary assumption is that the integrat ion of the radial equilibrium equation 
may be performed along the j coordinate direction of the mesh. Hence, the j coordinate 
should be the radial-like direction. A single specification of static pressure is required at 
either the maximum or minimum extreme of the j coordinate of the boundary surface in 
order to initiate the integration process. The direction of integration and location of appli- 
cation of the specified exit static pressure are determined by the LSPEC1 variable in the 
calling sequence. If LSPEC1 = L, for LOW, then PEXIT is applied to the lower (smallest 
value) of the j index, and the radial equilibrium equation is integrated outward (increasing 
j direction). If LSPECl = H. for HIGH, then PEXIT is applied to the upper (largest 
value) of the j index, and the radial equilibrium equation is integrated inward (decreasing 
j direction). The remaining flow variables on the EXITT boundary are updated by a 
Reimann invariant formulation based on the resulting local static pressure field. Included 
in the EXITT procedure is a special correction scheme which forces the flow to pass out of 
the flow domain. In other words, if the computed velocities result in a local inflow at the 
EXITT boundary, no matter how small the magnitude of the inflow, the velocities are reset 
to zero at that point. This boundary condition requires the specification of additional data, 
as shown in the boundary data format descriptor above. The first additional line following 
the EXITT specification is assumed to be a label and may contain any information; how- 
ever, for consistency it is recommended that the label PEXIT be used. The line following 
the PEXIT label contains the value of specified non-dimensional exit static pressure used 
to initiate the radial equilibrium integration procedure. The value of the PEXIT variable 
is computed as follows: 


PEXIT 


f 3' tt static. 


,t If si red 


P, 


■*/ 


The variable P rf j are specified by the input variable PREF. Values of PEXIT <0.0 are 
not permitted. Nat urally, poor convergence or solution divergence can occur if the value of 
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PEXIT suggests boundary data which are significantly different from the remainder of the 
flowfield. In such cases where this occurs, it is recommended that the solution he started 
with more conservative boundary values, and then restarted using the final boundary values. 

An alternate specification is provided for the EXITT boundary specification as shown 
in the sample application above. In this case, three values are included following the original 
boundary specification line. The alternate specification is provided as a means of achieving 
a desired mass flow rate through the bounding surface using the EXITT algorithm. The 
desired mass flow rate is achieved iteratively by incrementally adjusting the exit static 
pressure specification until the desired flow rate is achieved. Therefore, in this specification, 
the variable PEXIT described in detail above is the initial exit static pressure used in the 
iterative process. EMDOT represents the desired mass flow rate through the bounding 
surface in pounds mass, and PRELAX is a relaxation factor to stabilize the iterative 
process (values may range from 0.0 to 1.0, though poor convergence is likely for values 
larger than 0.1). This procedure is not foolproof, and suffers from the fact that when a 
job is restarted, if an updated exit pressure is not inserted in the boundary data file, then 
the pressure-mass flow iterative process will essentially start over. The 1 I)l\ \( '07 code will 
automatically determine when to employ the iterative process by identifying the additional 
boundary specification variables. 


Restrictions /Limitations 


The EXITT boundary condition assumes that the mesh is oriented in such a fashion that 
the radial coordinate is defined as r = \J y 2 + z 2 . For axial flow turbomachinery, this implies 
that the axis of rotation (or the centerline) coincides with the .r axis. It is also required 
that the radial like direction of the mesh be defined by the j coordinate, and is therefore 
not valid on a j ^constant mesh plane. T his is required in order to properly integrate the 
radial equilibrium equation to complete the exit static pressure specification. Examples 
of this type of mesh system can be found in the chapter defining standard configurations. 
The EXITT boundary specification is restricted to :M) mesh surfaces (2-1) mesh surfaces 
should use the EXT2DT boundary specification). 


Common Errors 


• Application of EXITT to a 2 1) mesh system. 

• Failure to specify the additional data value PEXIT. 

• Improper specification of the alternate (mass flow) iterative scheme. 

• Haxlial-like direction of the mesh is not the j coordinate. 

• Mesh does not possess circumferential symmetry (axial, radial mesh coordinates vary 
in the circumferential coordinate direction). 

• Failure to properly specify the LSPEC1 variable on the boundary data file specifica- 
tion line. 
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Value of PEXIT is too high (flow cannot get started). 
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EXITX 


Non- Reflecting Steady State Turbomaoliiiiciy Exit Boundary 
Condition 


Mesh Block #1 


(49x17x17) 

\ 



# 





Pressure Flow Angle 

Static pressure specified at either lower 
or upper Y boundary 

Radial equilibrium equation integrated 
to complete exit static pressure specification 

Specified Exit Static Pressure and Radial 
Equilibrium for Non- reflecting T urbomachinery 
Exit Flow Requires an EXITX Specification 


Application 


The EXITX specification is used to impose a non-reflecting turbomachinery-based exit 
boundary condition based on radial equilibrium ior steady flow calculations. 1 he illustrative 
graphic above depicts an application of the EXITX outflow boundary condition for an 11- 
t vpe mesh for a t urbomachinery fan rotor blade passage. The EXITX specification provides 
t he radial variation of flow properties at the outflow boundary resulting from the application 
of a simplified form of the radial equilibrium equation. This boundary condition has been 
utilized extensively as a non -reflecting exit flow specifier for both ducted and unducted 
t urbomachinery flows. 


Boundary Data File Format 


The boundary datafile specification for the mesh surface indicated in the illustrative graphic 
for the EXITX boundary condition is given below: 

EXITX 1 1 I I M M L L 49 49 1 17 1 17 1 17 1 17 

PEXIT 

1.105 
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Note that a complete EXITX specification requires two additional lines following the EX- 
ITX boundary data file specification line. Failure to properly specify the data in these 
additional lines is a common EXITX specification error. It should also be mentioned that 
EXITX also requires proper specification of the LSPECl variable for proper execution. 


Description 


The EXITX keyword specifies that a non-reflecting turboma.chinery-ba.sed radial equilib- 
rium exit flow boundary condition is to be applied to the mesh surface specified by LFACEl 
on the block specified by LBLOCK1. The EXITX boundary condition was specifically 
designed as a non-reflecting exit flow boundary procedure for steady state analysis of ax- 
ial and mixed flow turbomachinery geometries (pure radial flow turbomachinery exit flow 
boundaries may usually be specified by the EXITG boundary condition). The EXITX 
boundary condition procedure utilizes a combination static pressure specification and in- 
tegration of the radial equilibrium equation to define the circumferentially averaged static 
pressure field at all points on the boundary surface. The circumferentially-averaged pres- 
sure at the exit boundary is forced to match the imposed static pressure. The use of the 
circumferential average permits flow properties to vary across the exit plane, while still 
maintaining the desired overall flow (additional details for this procedure are given in the 
final report [21]. As a result of the complexity of this procedure, several mesh restrictions 
were imposed to simplify the application of this approach. The primary assumption is that 
the integration of the radial equilibrium equation may be performed along the j coordi- 
nate direction of the mesh. Hence, the j coordinate should be the radial-like direction. 
A single specification of static pressure is required at either the maximum or minimum 
extreme of the j coordinate of the boundary surface in order to initiate the integration 
process. The direction of integration and location of application of the specified exit static 
pressure are determined by the LSPECl variable in the calling sequence. If LSPECl = 
L, for LOW, then PEXIT is applied to the lower (smallest value) of the j index, and the 
radial equilibrium equation is integrated outward (increasing j direction). If LSPECl = 
H, for HIGH, then PEXIT is applied to the upper (largest value) of the j index, and the 
radial equilibrium equation is integrated inward (decreasing j direction). The remaining 
flow variables on the EXITX boundary are updated by a Reimann invariant formulation 
based on the resulting local static pressure field. Included in the EXITX procedure is a 
special correction scheme which forces the flow to pass out of the flow domain. In other 
words, if the computed velocities result in a local inflow at the EXITX boundary, no matter 
how small the magnitude of the inflow, the velocities are reset to zero at that point. This 
boundary condition requires the specification of additional data, as shown in the boundary 
data format descriptor above. The first additional line following the EXITX specification 
is assumed to be a label and may contain any information; however, for consistency it is 
recommended that t he label PEXIT be used. The line following the PEXIT label contains 
the value of specified non-dimensional exit static pressure used to initiate the radial equi- 
librium integration procedure. The value of the PEXIT variable is computed as follow's: 

PE X IT ^cJ'itstatic.df sirfd 

Przj 

The variable P rf j are specified by the input variable PREF. Values of PEXIT <0.0 are 
not permitted. Naturally, poor convergence or solution divergence can occur if the value of 
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PEXIT suggests boundary data which are significantly different from the remainder of the 
flowfield. In cases where this occurs, it is recommended that the solution be started with 
more conservative boundary values, and then restarted using the final boundary values. 


Rostrictioiis/Liinitations 


The EXITX boundary condition assumes that the mesh is oriented in such a fashion that 
the radial coordinate is defined as r = vV + — For axial flow turbomachinery, this implies 
that the axis of rotation (or the centerline) coincides with the .v axis. It is also required 
that the radial-like direction of the mesh be defined by the j coordinate, and is therefore 
not valid on a j =constant mesh plane. This is required in order to properly integrate the 
radial equilibrium equation to complete the exit static pressure specification. Examples of 
t his t vpe of mesh system can be found in the chapter defining standard configurations. I he 
EXITX boundary specification is restricted to 3-1) mesh surfaces. The EXITX boundary 
condition is only valid for steady state flow calculations (a non-reflecting exit flow boundary 
conditions is available with EXITN). 


Common Errors 


• Application of EXITX to a 2-1) mesh system. 

• Failure to specify the additional data value PEXIT. 

• Radial-like direction of the mesh is not the j coordinate. 

• Mesh does not possess circumferential symmetry (axial, radial mesh coordinates vary 
in the circumferential coordinate direction). 

• Failure to properly specify the LSPECl variable on the boundary data file specifica- 
tion line. 

• Value of PEXIT is too high (flow cannot get started). 

• Application of EXITX for time-dependent flow calculations. 
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FIXED 


Fixed Flow Boundary Specific ation 


Secondary 

Flow 


* 


FIXED Boundary Specification 
Used to Simulate Secondary 


Primary 

Flow 




Application 


The FIXED specification is used as a “last, resort” boundary specification which hardwires 
flow properties into the numerical solution. The application illustrated above indicates an 
application of the FIXED boundary specification to provide a direct implementation of the 
flow properties of an injection jet into a simple duct flow. The same jet could have been 
modeled more effectively using alternate boundary conditions, or through the addition of an 
additional grid to simulate 1 lie jet flow passage; however, for the purposes of demonstration, 
and to obtain a solution of this type quickly, the FIXED specification was used instead. 


Boundary Data File Format 


The boundary data, file specifications for the mesh interface indicated in the illustrative 
graphic for the FIXED boundary condition are given below: 


FIXED 1 1 J J P P I K 1 1 11 21 1 11 11 21 1 11 

R0 U V W HOT 
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0.002 100.0 100.0 0.0 600.0 

Mole that a complete FIXED specification requires the specification of additional data 
beyond the standard boundary specification line. 


Description 


The FIXED statement is used to provide a fixed specification of boundary flow data in the 
absence of any other appropriate boundary condition. This routine was provided for those 
cases where other boundary conditions either cannot provide the boundary specifications 
desired, or in those cases where a fixed boundary specification is deemed appropriate. In 
most case's, the FIXED specification is undesirable because the boundary condition itsell is 
perfectly reflecting, and will therefore inhibit solution convergence. In addition, the FIXED 
specification does nol permit interaction between the boundary flow and tlx' interior flow, 
which runs contrary to the* normal fluid dynamics behavior. 

A FIXED specification requires two additional lines in addition to the normal boundary 
data file descriptor, as shown above. The first additional line simply contains the labels for 
the additional flow variable RO, U. V. W. and TTOT. The next line contains the actual 
values for t he flow variable specifications. The variable RO defines the fluid density in slugs 
per cubic foot. The variables U. V. and W contain the fluid velocity components in feet 
per second for the .r, i/, and r coordinate directions for a (’artesian solution mesh block, 
and the .r. r. and 0 coordinate directions for a cylindrical solution mesh block, respectively. 
Finally. TTOT represents the fluid total temperature in degrees Rankine for the boundary 
specification. During the application of a FIXED specification, phantom boundary cell 
data are set according to the data provided in the extra lines following the boundary data 
specification line as shown above. As a result, the data is not necessarily applied at the 
boundary, but the influence of the data is felt just outside the boundary. This phenomenon 
is consistent with the behavior of a finite volume solution algorithm. 

Restrict ions /Limitations 

Data provided in the FIXED specification should represent phantom cell centered data 
and must be dimensionalized as described above. 


Common Errors 


• Incorrectly specified or misaligned extents of boundary regions (values of M1LIM1, 
M1LIM2, N1LIM1, N1LIM2, M2LIM1, M2LIM2, N2LIM1, N2LIM2 do not 
correctly define the interface extents on blocks LBLOCKl and LBLOCK2). 

• Failure to provide additional data for FIXED specification. 

• FIXED boundary specifications for cylindrical solution mesh blocks must use the 
cylindrical velocity components. 
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FIXED boundary specifications for Cartesian solution mesh blocks must use the 
Cartesian velocity components. 
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FRE2D 


2-D Far Field Flow Boundary Condition 


Far Field Boundary with Angled 
Flow Requires a FRE2D Specification 



Application 


The FRE2D specification is used to impose a far field boundary condition with uniform 
far field flow properties. The example graphic above illustrates a four block mesh system 
used to predict the axisymmetric flow through a high bypass ducted fan. The two outer 
blocks (#2 and #4) require a farfield boundary condition at the outer boundary (j=17). 
The FRE2D boundary specification is used to satisfy the farfield flow requirement. This 
boundary condition has been utilized extensively for both ducted and unducted 2-D fan 
propulsion systems. 


Boundary Data File Format 


The boundary data file specification for the mesh interface indicated in the illustrative 
graphic for the FRE2D boundary condition is given below: 


FRE2D 

2 2 

J J M 

M I K 

17 

17 

1 

129 

1 

2 

1 129 1 

2 

Block 

2 

PTOT 

TTOT 

EMINF 

ALPHA 











1.0 

1.0 

0.75 

0.0 











FRE2D 

4 4 

J J M 

M I K 

17 

17 

1 

97 

1 

2 

1 97 1 

2 

Block 

4 

PTOT 

TTOT 

EMINF 

ALPHA 











1.0 

1.0 

0.75 

0.0 
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Note that a complete FRE2D specification requires two additional lines following the 
FRE2D boundary data file specification line. Failure to properly specify the data in these 
additional lines is a common FRE2D specification error. 


Description 


The FRE2D statement specifies that an external* free flow boundary condition is to be ap- 
plied to the mesh surface specified by LFACE1 on the 2-D block specified by LBLOCK1. 
The FRE2D boundary condition is primarily used for external flow problems at a far field 
boundary to simulate the effects of the atmosphere or other large reservoir with known 
properties. The FRE2D procedure utilizes a Reimann invariant formulation to compute 
the local flow quantities, and permits both inflow and outflow through the bounding surface 
based on t he nature of the local flow with respect to the known far field conditions. This 
boundary condition requires the specification of additional data, as shown in t he boundary 
data format descriptor above. The first additional line following the FRE2D specifica- 
tion is assumed to be a label and may contain any information; however, for consistency 
it is recommended that the labels PTOT. TTOT. EMINF, and ALPHA be used. The 
next line contains the values imposed for the variables PTOT. TTOT. EMINF. and 
ALPHA. which represent the far field nondimensional reservoir total pressure and total 
temperature, along with the Mach number and Cartesian angle of attack, respectively, used 
in the FRE2D characteristic solution sequence. The value of the PTOT variable is the 
desired normalized far field total pressure computed as: 


PTOT 


F total, desired 


rt / 


and the value of the TTOT variable is the desired normalized far field total temperature 
computed as: 


TTOT = 


- toiaLdt sired 


T 


Tff 


The variables P rf j and T re j are specified by the input variables PREF and TREF. Values 
of PTOT and TTOT <0.0 are not permitted. The variable EMINF represents the far 
field Mach number. The far field flow is always assumed to progress along the positive x axis, 
and therefore mesh systems should be generated with this in mind. Finally, the variable 
ALPHA represents the farfield Cartesian angle of attack, in degrees, relative to the x axis, 
with positive angles resulting in far field velocity components in the z coordinate direction. 
For 2-D flows, this must virtually always be zero. The angle of attack velocities are always 
in the x-z plane and the velocity components in the y coordinate direction are always zero. 
If there is outflow along the FREE boundary, then some small y component velocities may 
occur as a result of extrapolation from the near field flow. Naturally, poor convergence or 
solution divergence can occur if PTOT, TTOT, EMINF or ALPHA suggest boundary 
values which are significantly different from the remainder of the flowfield. In such cases 
where this occurs, it is recommended that the solution be started with more conservative 
boundary values, and then restarted using the final boundary values. 


Restrictioiis/Limitations 
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The FRE2D boundary specification is not restricted to 2-1) mesh surfaces, although for 
consistency 3-1) mesh surfaces may use the FREE boundary specification. For 2 1) appli- 
cations. t he far field flow angle of at t ack must usually be zero. 


Common Errors 


• Failure to specify the additional data values PTOT. TTOT. EMINF. or ALPHA. 

• ALPHA h as a nonzero value. 

• Failure 1o generate the mesh with +.r as the primary flow direction. 
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FREE 


Far Field Flow Boundary Condition 


Mesh Block #4 
(49x9x13) 


Mesh Block #2 
(65x9x13) 



Far Field Flow at 
Angle of Attack 


Far Field Boundary with Angled 
Flow Requires a FREE Specification 


Mesh Block #3 Mesh Block #1 
(49x9x13) (65x9x13) 


Application 


The FREE specification is used to impose a far field boundary condition with uniform far 
field flow properties. The example graphic above illustrates a four block mesh system used 
to predict the 3-D flow through a high bypass ducted fan. The t wo outer blocks ( #2 and #4 ) 
require a farfield boundary condition at the outer boundary (j= 9). The FREE boundary 
specification is used to satisfy the farfield flow requirement. This boundary condition has 
been utilized extensively for both ducted and unducted fan propulsion systems including 
angle of attack cases. 


Boundary Data File Format 


The boundary data file specification for the mesh interfaces indicated in the illustrative 
graphic for the FREE boundary condition are given below: 


FREE 

2 

2 J 

J M 

M I K 

9 

9 

1 65 

1 

13 

1 

65 

1 

13 

Block 

2 

PTOT 


TTOT 

EMINF 

ALPHA 












1.0 


1.0 

0.75 

10.0 












FREE 

4 

4 J 

J M 

M I K 

9 

9 

1 49 

1 

13 

1 

49 

1 

13 

Block 

4 

PTOT 


TTOT 

EMINF 

ALPHA 












1.0 


1.0 

0.75 

10.0 
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Note t hat a complete FREE specification requires two additional lines following the FREE 
boundary data file specification line. Failure to properly specify the data in these additional 
lines is a common FREE specification error. 


Description 


The FREE statement specifies that an external, free flow boundary condition is to be 
applied to the mesh surface specified by LFACEl on the block specified by LBLOCKl. 
The FREE boundary condition is primarily used for external flow problems at a far field 
boundary to simulate the effects of the atmosphere or other large reservoir with known 
properties. The FREE procedure utilizes a Reimann invariant formulation to compute the 
local flow quantities, and permits both inflow and outflow through the bounding surface 
based on the nature of the local flow with respect to the known far field conditions. This 
boundary condition requires the specification of additional data, as shown in the boundary 
data formal descriptor above. The first additional line following the FREE specification 
is assumed to be a label and may contain any information: however, for consistency it is 
recommended that the labels PTOT. TTOT. EMINF, and ALPHA be used. The next 
line contains the values imposed for the variables PTOT, TTOT, EMINF. and ALPHA, 
which represent the far field nondimensional reservoir total pressure and total temperature, 
along with the Mach number and Cartesian angle of attack, respectively, used in the FREE 
characteristic solution sequence. The value of the PTOT variable is the desired normalized 
far field total pressure computed as: 

F I O I I lotnMfsirrd 

Frf f 

and the value of the TTOT variable is the desired normalized far field total temperature 
computed as: 


I I O F I totul, Uc s i r r d 

T >-fj 

The variables F rf j and T rf j are specified by the input variables PREF and TREF. Values 
of PTOT and TTOT <0.0 are not permitted. The variable EMINF represents the 
far field Mach number. The far field flow is always assumed to progress primarily along 
the positive x axis, and therefore mesh systems should be generated with this in mind. 
Finally, the variable ALPHA represents the farfield (’artesian angle of attack, in degrees, 
relative to the x axis, with positive angles resulting in far field velocity components in the 
~ coordinate direction. The angle of attack velocities are always in the x-z plane and the 
velocity components in the y coordinate direction are always zero. If there is outflow along 
the FREE boundary, then some small y component velocities may occur as a result of 
extrapolation from the near field flow. Naturally, poor convergence or solution divergence 
can occur if PTOT. TTOT, EMINF or ALPHA suggest boundary values which are 
significantly different from the remainder of the flowfield. In such cases where this occurs, 
it is recommended that the solution be started with more conservative boundary values, 
and then restarted using the filial boundary values. 


Restrictioiis/Limitatioiis 
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The FREE boundary specification is not restricted to 3-D mesh surfaces, although 2-D 
mesh surfaces may use the FRE2D boundary specification for consistency. The far field 
flow angle of attack must be specified relative to the .r axis, and produces additional velocity 
components in the s coordinate direction only. Imposed far- field velocity components in 
the y coordinate direction will always be zero. 


Common Errors 


• Application of FREE to a boundary for which far field y coordinate direct ion velocity 
components are required. 

• Failure to specify the additional data values PTOT. TTOT. EMINF. or ALPHA. 

• Failure to generate the mesh with +.r as the downstream flow direction. 
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INLETA 

Cartesian Anglo of Attack Inflow Boundary Condition Proce- 
dure 


Mesh Block #4 Mesh Block #2 

(49x9x13) (65x9x13) 



Mesh Block #3 Mesh Block #1 INLETA Specification 

(49x9x13) (65x9x13) 


Application 

The INLETA specification is used to impose a Cartesian angle of attack inflow boundary 
condition with uniform flow properties at a local mesh surface. The illustrative graphic 
above depicts a four block mesh system for a turbofan engine geometry. The INLETA 
specifier is ut ilized at the inlet of mesh blocks 1 and 2 to set the angled inflow necessary to 
simulate angle of attack. This boundary condition has been utilized extensively as an inlet 
flow specifier for inlet, nacelle, and propfan geometries at angle of attack. 

Boundary Data File Format 

The boundary data file specification for the mesh boundaries indicated in the illustrative 
graphic for the INLETA b oundary condition are given below: 

INLETA 11IIPPJK1 11 9113 1 91 13 

PTOT TTOT ALPHA 

1.0 1.0 20.0 

INLETA 22IIPPJK1 11 9113 1 91 13 
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PTOT TTOT ALPHA 

1.0 1.0 20.0 


Note that a complete INLETA specification requires two additional lines following the 
INLETA boundary data file specification line. Failure to properly specify the data in 
these additional lines is a common INLETA specification error. 


Description 


The INLETA keyword specifies that a uniform property angle of attack inflow boundary 
condition is to be applied to the mesh surface specified by LFACEl on the block specified 
by LBLOCK1. INLETA is valid for both cylindrical and (’artesian solution meshes (see 
the description of the input variable FCART). The INLETA procedure utilizes a Reimann 
invariant formulation to compute inflow velocities based on a specified upstream reservoir 
total pressure and total temperature, and a single Cartesian flow angle as shown in the illus- 
trative graphic, above. Included in the INLETA procedure is a special correction scheme 
which forces t he flow to pass into the flow domain. In other words, if the computed velocities 
result in a local outflow at the INLETA boundary, no matter how small the magnitude of 
the outflow, the velocities are reset to zero at that point. This boundary condition requires 
the specification of additional data, as shown in the boundary data format descriptor above. 
The first additional line following the INLETA specification is assumed to bo a label and 
may contain any information: however, for consistency it is recommended that the labels 
PTOT. TTOT. and ALPHA be used. The next line contains the values imposed for 
the variables PTOT. TTOT and ALPHA which represent the upstream reservoir total 
pressure, total temperature, and (’artesian flow angle, respectively, used in the INLETA 
characteristic solut ion sequence. The value of the PTOT variable is the desired normalized 
upstream total pressure computed as: 


PTOT = 


Pt 


total At sired 


P rt f 


and the value of the TTOT variable is the desired normalized upst ream total temperature 
computed as: 


TTOT = 


Tidal. 


desired 


l Tf j 


The variables P rt j and T rf j are specified by the input variables PREF and TREF. Values 
of PTOT and TTOT <0.0 are not permitted. The variable ALPHA represents the flow 
angle in degrees referenced to the ,r axis. For d-D applications, positive flow angles generate 
components of the flow in the positive r direction, and inlet velocity component in the y 
direction are set to zero. For 2-D applications, positive flow angles generate components 
of the flow in the positive y direction, and inlet velocity component in the ^ direction 
are set to zero. Values of ALPHA must lie between +/- 90 degrees. Naturally, poor 
convergence or solution divergence can occur if PTOT or TTOT suggest boundary values 
which are significantly different from the remainder of the llowfield. or if ALPHA is very 
large. In cases where this occurs, it is recommended that the solution be started with more 
conservative boundary values, and then restarted using the final boundary values. 
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Rostrictioiis/Limitations 

The INLETA boundary specification may be applied to either 3-1) or 2-D mesh surfaces. 
For 2-D applications, the angle specified by ALPHA is assumed to be in the positive y 
coordinate. An example of this type of application is for a planar cascade flow where x is the 
primary flow direction, and the inflow is at an angle of 20 degrees relative to the x axis, thus 
resulting in a y component of velocity (2-D only). The angle of the velocity components 
specified by the INLETA procedure must always be referenced to the .r coordinate axis, 
and it is left to the user to generate a mesh which is consistent with this feature. 

Common Errors 


• Application of INLETA to a 3-D mesh boundary for which non-zero ij component 
velocities are required. 

• Application of INLETA to a 2-1) mesh boundary for which non-zero ~ component 
velocities are required. 

• Failure to specify the additional data values PTOT. TTOT, or ALPHA. 
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INL2DG 


Generic Inflow Boundary Condition 



2-D Mesh Block #2 
(28x9x1) 


2-D Mesh Block #1 
(28x23x1) 


Inlet with Uniform j 

Normal Flow Requires an 
INL2DG Specification 


Application 


The INL2DG specification is used to impose a generic inflow boundary condition with 
uniform flow properties where the inflow velocity is normal to the local mesh surface. The 
example graphic above illustrates a 2-D 2- block mesh system mixing two adjacent streams 
of varying inlet properties. In this case, the INL2DG boundary specification is used to set 
the inflow boundary separately for each block to provide the desired incoming stream flow 
properties. This boundary condition has been utilized extensively as an inlet flow specifier 
for 2-D duct flows. 


Boundary Data File Format 


The boundary data file specification for the two mesh surfaces indicated in the illustrative 
graphic for the INL2DG boundary condition are given below; 


INL2DG 11IIPPJK 1 11 23 1 21 23 1 2 
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PTOT HOT 
1.0 1.0 

INL2DG 22IIPPJK1 11 91 21 91 2 

PTOT TTOT 

1.2 1.8 


Nolo that a complete INL2DG specification requires two additional lines following the 
INL2DG boundary data file specification line. Failure to properly specify the data in 
these additional lines is a common INL2DG specification error. 


Description 


The INL2DG statement specifies that a generic, uniform normal inflow boundary condi- 
tion is to be applied to the 2-1) mesh surface specified by LFACE1 on the block specified 
by LBLOCK1. The INL2DG 1 toundary condition should be applied for those cases where 
any other ’‘specialized” inflow boundary condition (such as INL2DT. etc.) does not apply. 
The INL2DG boundary condition is also likely to be somewhat more efficient computation- 
ally than the other inflow boundary condition procedures, at the expense of some physical 
simplification. INL2DG is valid for either cylindrical or Cartesian-based (see the input 
variable FCART) solutions on 2-1) meshes. The INL2DG procedure utilizes a Reimann 
invariant formulation to compute inflow velocities based on a specified upstream reservoir 
total pressure and total temperat ure. The velocity components at an INL2DG boundary 
are always computed to be normal (no transverse velocity components) to the local cell 
face at which the procedure is applied. Included in the INL2DG procedure is a special 
correction scheme which forces the flow to pass into the flow domain. In other words, if 
the computed velocities result in a local outflow at the INL2DG boundary, no matter how 
small the magnitude of the outflow, the velocities are reset to zero at that point. This 
boundary condition requires the specificat ion of additional data, as shown in the boundary 
data format descriptor above. The firsl additional line following the INL2DG specification 
is assumed to be a label and may contain any information: however, for consistency it is 
recommended that, the labels PTOT and TTOT be used. 4 he next line contains the values 
imposed for the variables PTOT and TTOT. which represent the upstream reservoir total 
pressure and total temperature, respectively, used in the INL2DG characteristic solution 
sequence. The value of the PTOT variable is the desired normalized upstream total pres- 
sure computed as: 


PTOT 


Pldliil.df sirfil 
Pr.J 


and the value of the TTOT variable is the desired normalized upstream total temperature 
computed as: 


7 TOT — 1 s ‘ rr 'i 
Tr< f 

The variables P r( j and T, f ; are specified by the input variables PREF and TREF. Values 
of PTOT and TTOT <0.0 are not permitted. Naturally, poor convergence or solution 
divergence can occur if PTOT or TTOT suggest boundary values which are significantly 



144 


INL2DG - ADPAC07 Boundary Data File Specifications 


different from the remainder of the flowfield. In such cases where this occurs, il is rec- 
ommended that the solution be started with more conservative boundary values, and then 
restarted using the final boundary values. 


Restrictions /Limitations 


The INL2DG boundary specification is not restricted to 2-D mesh surfaces, although for 
consistency 3-D mesh surfaces may use the INLETG boundary specification. 


Common Errors 


• Application of INL2DG to a boundary for which transverse inflow velocity compo- 
nents are required. 

• Failure to specify the additional data values PTOT or TTOT. 
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INLETG 

Generic Inflow Boundary Condition 

Mesh Block #1 
(49x33x33) 


Flow 


Application 

The INLETG specification is used to impose a generic inflow boundary condition with 
uniform flow properties where the inflow velocity is normal to the local mesh surface. This 
boundary condition has been utilized extensively as an inlet flow specifier for duct flows 
and t urbine blade cooling flow. 

Boundary Data File Format 

The boundary data file specification for the mesh interface indicated in the illustrative 
graphic for the INLETG boundary condition is given below: 

INLETG 11IIPPJK 1 11 33 1 33 1 33 1 33 

PTOT TTOT AKIN ARIN 

1.0 1.0 0.001 0.0001 



INLETG Specification 
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Note that a complete INLETG specification requires two additional lines following the 
INLETG boundary data file specification line. Failure to properly specify the data in 
these additional lines is a common INLETG specification error. 


Description 


The INLETG statement specifies that a generic, uniform normal inflow boundary condi- 
tion is to be applied to the mesh surface specified by LFACE1 on the block specified by 
LBLOCKl. The INLETG boundary condition should be applied for those cases where 
any other "specialized*" inflow boundary condition (such as INLETR, INLETT. etc.) 
does not apply. The INLETG boundary condition is also likely to be somewhat more effi- 
cient computationally than the other inflow boundary condition procedures, at the expense 
of some physical simplification. INLETG may be utilized on either cylindrical or Carte- 
sian solution meshes (see the description of the input variable FCART). The INLETG 
procedure utilizes a Reiman n invariant formulation to compute inflow velocities based on a 
specified upstream reservoir total pressure and total temperature. The velocity components 
at an INLETG boundary are always computed to be normal (no transverse velocity com- 
ponents) to the local cell face at which the procedure is applied. Included in the INLETG 
procedure is a special correction scheme which forces the flow to pass into the flow domain. 
In other words, if the computed velocities result in a local outflow at the INLETG bound- 
ary. no matter how small the magnitude of the outflow, the velocities are reset to zero at 
that point. This boundary condition requires the specification of additional data, as shown 
in the boundary data format descriptor above. The first additional line following the IN- 
LETG specification is assumed to be a label and may contain any information; however, for 
consistency it is recommended that the labels PTOT. TTOT. AKIN, and ARIN be used. 
The next line contains the values imposed for the variables PTOT. TTOT, AKIN, and 
ARIN. which represent the upstream reservoir total pressure, total temperature, turbu- 
lence kinetic energy, and turbulence Reynolds number, respectively, used in the INLETG 
characteristic solution sequence. The value of the PTOT variable is the desired normalized 
upstream total pressure computed as: 


PTOT = 


Pto 


tal.de sired 

I'rrf 


and the value of the TTOT variable is the desired normalized upstream total temperature 
computed as: 


TTOT ^ total, desired 

Tref 

The variables P rc j and T rf j are specified by the input variables PREF and TREF. Values 
of PTOT and TTOT <0.0 are not permitted. Naturally, poor convergence or solution 
divergence can occur if PTOT or TTOT suggest boundary values which are significantly 
different from the remainder of the flowfield. In such cases where this occurs, it is rec- 
ommended that the solution be started with more conservative boundary values, and then 
restarted using the final boundary values. 

The variable AKIN and ARIN are only used when the 2-equation (A- - Tv) turbulence 
model is enabled (see the description of the input file variable F2EQ). When enabled, the 
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variable AKIN represents the value of t he nondimensional freest ream turbulence kinetic 
energy defined by k/V*.j where k is the freestream turbulent kinetic energy and Y rf j is the 
reference velocity defined by \/ B r , j l r , / . Here R rf j is the gas constant (see [21] for addi- 
tional details). The variable ARIN represent the so-called freestream turbulence Reynolds 
number (again see [21]) and is calculated as 7v/V rf j L rf j . where L rf j is the lefeienre length 
defined by the input variable DIAM. 


Restrictions /Limitations 


The INLETG boundary specification is not restricted to 3-D mesh surfaces (although for 
consistency 2-D mesh surfaces may use the INL2DG boundary specification). 

Common Errors 


• Application of INLETG to a boundary for which transverse inflow velocity compo- 
nents are required. 

• Failure to specify the additional data values PTOT or TTOT. 
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INLETR 


Radial Flow Turbomaohinery Inflow Boundary Condition 


Flow 



Application 


The INLETR specification is used to impose an inflow boundary condition with axially 
varying flow properties for radial flow turbomachinery. The example graphic above illus- 
trates adjacent passages of a mesh system designed to predict the flow through a radial 
diffuser. The inlet boundary is a radial surface of revolution with properties which vary 
in the axial direction, and therefore INLETR is used to supply the desired flow char- 
acteristics at this boundary. INLETR has been successfully used for several radial flow 
turbomachinery geometries. 

Boundary Data File Format 


The boundary data file specification for the mesh surface indicated in the illustrative graphic 
for the INLETR boundary condition is given below: 

INLETR 1 1 I I P P J K 1 1 1 13 1 17 1 13 1 17 

NDATA 
4 

AXIAL PTOT TTOT BETAX BETAT 

0.1 0.99 0.99 5.0 -73.3 
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0.2 

0.98 

1.01 

4.0 

- 75.8 

0.3 

0.97 

1.00 

3.0 

- 77.2 

0.4 

0.96 

1.01 

2.0 

- 79.0 


A complete INLETR specification requires at least six additional lines (defining at least 
3 points on the inlet data distribution) following the INLETR boundary data file spec- 
ification line. Failure to properly specify the data in these additional lines is a common 
INLETR specification error. 


Description 


The INLETR statement specifies that an axial flow turbomachinery inlet flow boundary 
condition with axially varying flow properties is to be applied to the mesh surface specified 
by LFACE1 on the block specified by LBLOCK1. The INLETR boundary condition was 
specifically designed as an inflow boundary procedure for pure radial flow turbomachinery 
geometries (axial and mixed flow turbomachinery inflow boundaries may be specified by the 
INLETT boundary condition). The INLETR procedure utilizes a Reimann invariant for- 
mulation to compute inflow velocities based on a specified axial variation in flow properties 
(upstream reservoir total pressure, total temperature, axial flow angle, and circumferential 
flow angle)- Included in the INLETR procedure is a special correction scheme which forces 
the flow to pass into the flow domain. In other words, if the computed velocities result in a 
local outflow at the INLETR boundary, no matter how small the magnitude of the outflow, 
the velocities are reset to zero at that point. This boundary condition requires the specifi- 
cation of additional data, as shown in the boundary data format descriptor above. I he first 
additional line following the INLETR specification is assumed to be a label and may con- 
tain any information: however, for consistency it is recommended that the label NDATA 
be used. The line following the NDATA label contains the number of axial data points 
which will be used to specify the desired axial variation of properties at the inflow boundary. 
At least 3 axial data locations must be specified to use the INLETR boundary condition. 
The third line following the INLETR specifier is again a label which outlines the variables 
AXIAL, PTOT, TTOT, BETAX and BETAT. The remaining NDATA lines contain 
the numeric information which defines t he axial variation of the flow properties specified by 
these variables. The variable AXIAL is the axial coordinate (remember, the centerline is 
the x axis) at which the data is specified. This value should be nondimensionalized in the 
same manner as the mesh is nondimensionalized. This implies that the AXIAL variable, 
when multiplied by the input variable DIAM will result in the true geometric measure- 
ment in feet. Due to the interpolation procedures which will ultimately be performed on the 
NDATA lines of radial inflow data, it is essential that the axial variations be specified in 
a monotonic (constantly increasing) fashion. The variables PTOT and TTOT represent 
the local upstream reservoir total pressure and total temperature, respectively, used in the 
INLETR characteristic solution sequence. The value of the PTOT variable is the desired 
normalized upstream total pressure computed as: 

nr nr — ^ total, (if si If rl 

1 1 UJ - J— 

1 ''ff 

and the value of the TTOT variable is the desired normalized upstream total temperature 
computed as: 
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TTOT 


T total, desired 

T re f 


The variables P rt j and T r( j are specified by the input variables PREF and TREF. Values 
of PTOT and TTOT <0.0 are not permitted. The variables BETAX and BETAT 
represent the local axial and circumferential flow angles expressed in degrees according to 
the coordinate orientation defined in Figure 3.8. 


Naturally, poor convergence or solution divergence can occur if any of the values of 
PTOT.TTOT. BETAX. or BETAT suggest boundary values which are significantly dif- 
ferent from the remainder of the flowfield, or if the axial variation of these values is exces- 
sively large. In such cases where this occurs, it is recommended that the solution be started 
with more conservative boundary values, and then restarted using the final boundary val- 
ues. 


Restrictions/ Limitations 


The INLETR boundary condition assumes that the mesh is oriented in such a fashion 
that the radial coordinate is defined as r = \/y 2 + z 2 . For radial flow turbomachinery, 
this implies that the axis of rotation (or the centerline) coincides with the x axis. It is 
also required that the axial-like direction of the mesh be defined by the j coordinate. An 
example of this type of mesh system can be found in the illustrative graphic included at 
the beginning of this description. 


Common Errors 


• Failure to specify the additional data values NDATA. AXIAL. PTOT. TTOT. 
BETAX. or BETAT. 

• Axial-like direction of the mesh is not the j coordinate. 

• NDATA less than 3, resulting in job termination. 

• BETAX and/or BETAT orientation incorrectly interpreted. 

• AXIAL, PTOT and/or TTOT improperly normalized. 

• Mesh /geometry not defined with the x axis as the centerline. 



ADPAC07 Boundary Data File Specifications - INLETR 


151 


Axial Flow Angle Circumferential Flow Angle 


r 


x 



Figure :{.X: ADPAC07 INLETR boundary specification flow angle reference 
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INL2DT 


2-D Turbomachinery Inflow Boundary Condition 


2-D Mesh Block «1 



Radial Variation of Turbomachinery Inlet T 

Flow Variables Requires an INL2DT Specification J 

(illustrated in Boundary Data File Format 1 

statements below) i 


Application 


The INL2DT specification is used to impose an inflow boundary condition with radially 
varying flow properties for 2-D axisvmnietric mesh systems. The example graphic illus- 
trated above depicts an EXT2DT specification for a 2-D (axisvmnietric) flow solution for 
a turbomachinery blade row. This boundary condition has been utilized extensively as ail 
inlet flow specifier for 2-D turbomachinery flow passages and solutions for embedded blade 
rows with imposed axisvmnietric body forces. 


Boundary Data File Format 


The boundary data file specification for the mesh surface indicated in the illustrative graphic 
for the INL2DT boundary condition is given below: 

INL2DT 11IIPPJK1 1117 1 2117 1 2 

NDATA 
7 

RAD PTOT TTOT BETAR BETAT 

0.20 1.01 0.98 5.0 5.1 
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0.25 

1.01 

0.99 

4.0 

5.7 

0.30 

1.00 

1.00 

3.0 

6.3 

0.35 

0.99 

1.01 

2.5 

6.8 

0.40 

0.97 

1.00 

2.0 

7.4 

0.45 

0.96 

1.01 

1.0 

8.0 

0.50 

0.95 

1.01 

0.0 

7.7 


A complete INL2DT specification requires at least six additional lines (defining at least 3 
points on t he inlet data. distribut ion ) following t he INL2DT boundary data file specification 
line. Failure to properly specify the data in these additional lines is a common INL2DT 
specification error. 


Description 


The INL2DT statement specifies that a turbomachinery-based radially varying inflow 
boundary condition is to be applied to the 2-D mesh surface specified by LFACEl on 
the block specified by LBLOCKl. The INL2DT boundary condition was specifically 
designed as an inflow boundary procedure for axial and mixed flow axisymmetric turboma- 
chinery geometries (radial flow turbomachinery inflow boundaries may be specified by the 
INL2DR boundary condition). The INL2DT procedure utilizes a Riemann invariant for- 
mulation to compute inflow velocities based on a specified radial variation in flow properties 
(upstream reservoir total pressure, total temperature, radial flow angle, and circumferential 
flow angle). Included in the INL2DT procedure is a special correction scheme which forces 
the flow to pass into the flow domain. In other words, if the computed velocities result in a 
local outflow at the INL2DT boundary, no matter how small the magnitude of the outflow, 
the velocities are reset to zero at that point. This boundary condition requires the specifi- 
cation of additional data, as shown in the boundary data format descriptor above. The first 
additional line following the INL2DT specification is assumed to be a label and may con- 
tain any information; however, for consistency it is recommended that the label NDATA be 
used. The line following the NDATA label contains the number of radial data points which 
will be used to specify the desired radial variation of properties at the inflow boundary. At 
least 3 radial data locations must be specified to use the INL2DT boundary condition. 
The third line following the INL2DT specifier is again a label which outlines the variables 
RAD, PTOT, TTOT, BETAR and BETAT. The remaining NDATA lines contain the 
numeric information which defines the radial variation of the flow properties specified by 
these variables. The variable RAD is the radius (remember, the centerline is the .r axis) at 
which the data is specified. This value should be nondimensionalized in the same manner as 
the mesh is nondimensionalized. This implies that the RAD variable, when multiplied by 
the input variable DIAM will result in the true geometric measurement in feet. Due to the 
interpolation procedures which will ultimately be performed on the NDATA lines of radial 
inflow data, it is essential that the radial variations be specified from the inner to the outer 
radius in a monotonic (constantly increasing) fashion. The variables PTOT and TTOT 
represent the local upstream reservoir total pressure and total temperature, respectively, 
used in the INL2DT cha ract eristic solution sequence. The value of the PTOT variable is 
the desired normalized upstream total pressure computed as: 
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PTOT = 


P total, desi 
P ref 


and the value of the TTOT variable is the desired normalized upstream total temperature 
computed as: 


TTOT sir ed 

T rff 

The variables P rf j and T rf j are specified by the input variables PREF and TREF. Values 
of PTOT and TTOT <0.0 are not permitted. The variables BETAR and BETAT 
represent the local radial and circumferential flow angles expressed in degrees according to 
the coordinate orientation defined in Figure 4.9. Naturally, poor convergence or solution 
divergence can occur if any of the values of PTOT, TTOT, BETAR, or BETAT suggest 
boundary values which are significantly different from the remainder of the flowfield. or if 
the radial variation of these values is excessively large. In cases where this occurs, it is 
recommended that the solution be started with more conservative boundary values, and 
then restarted using the final boundary values. 


Restrictions / Limitations 


The INL2DT boundary condition assumes that the mesh is oriented in such a fashion 
that the radial coordinate is defined as r = vV 2 + — For axial flow turbomachinery, this 
implies that the axis of rotation (or the centerline) coincides with the x axis. It is also 
required that the radial-like direction of the mesh be defined by the j coordinate. Examples 
of this type of mesh system can be found in the chapter defining standard configurations. 
The INL2DT boundary specification is restricted to 2-D mesh surfaces (3-D mesh surfaces 
should use the INLETT boundary specification). 


Common Errors 


• Application of INL2DT to a 3-D mesh system. 

• Failure to specify the additional data values NDATA. PTOT, TTOT. BETAR. or 
BETAT. 

• Radial-like direction of the mesh is not the j coordinate. 

• NDATA less than 3, resulting in job termination. 

• BETAR and/or BETAT orientation incorrectly interpreted. 

• RAD. PTOT and/or TTOT improperly normalized. 

• Mesh/geometry not defined with the x axis as the centerline. 
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INLETN 


Non- Reflec ting Unsteady Inflow Boundary Condition 


Mesh Block #1 
(49x33x33) 



Flow 



Application 


The INLETN specification is used to impose a non-reflecting inflow boundary condition 
for time-dependent flow calculations. This boundary condition has been utilized for time- 
dependent flows where spurious numerical reflections from other boundary algorithms are 
undesirable. 

Boundary Data File Format 


The boundary data file specification for the mesh interface indicated in the illustrative 
graphic for the INLETN boundary condition is given below: 


INLETN 11IIPPJK1 11 33 1 33 1 33 1 33 
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Description 

The INLETN statement specifies that a generic, non-reflecting inflow boundary condi- 
tion is to be applied to the mesh surface specified by LFACE1 on the block specified by 
LBLOCKl. The INLETN boundary condition should only be applied for time-dependent 
flow calculations where spurious numerical reflections such as those normally expected from 
other boundary specifications (such as INLETR, INLETT. etc.) are undesirable. IN- 
LETN may be utilized on either cylindrical or Cartesian solution meshes (see the descrip- 
tion of the input variable FCART). The INLETN procedure utilizes a characteristic-based 
formulation to compute inflow velocities based on local flow conditions only. 

Restrictions /Limitations 

The INLETN boundary specification is not restricted to d-D mesh surfaces but should only 
be applied for time-dependent flow calculations where a non-reflecting inflow boundary is 
desired. 

Common Errors 


• Application of INLETN for a steady state solution. 
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INLETT 


Turbomaoliiiiery Inflow Boundary Condition 


Radius 


Radius 


1 

Total 
Pressure 

i 

Radial 

Flow Angle Flow Angle 


Mesh Block #1 



Radius 



Temperature 


Radius 



Circumferential 


Flow 




Radial Variation of Turbomachinery Inlet 
Flow Variables Requires an INLETT Specification 
(illustrated in Boundary Data File Format 
statements below) 



Application 

The INLETT specification is used to impose an inflow boundary condition with radially 
varying flow properties. The illustrative graphic above depicts an application of the IN- 
LETT inflow boundary condition for an H-type mesh for a turbomachinery fan rotor blade 
passage. The INLETT specification provides the radial variation of flow properties at 
the inflow boundary resulting from experimental conditions, upstream blade rows, or other 
known inlet property variation. This boundary condition has been utilized extensively as 
an inlet flow specifier for turbomachinery blade passages and annular ducts. 


Boundary Data File Format 


The boundary data file specification for the mesh surface indicated in the illustrative graphic 
for the INLETT boundary condition is given below: 

INLETT 11IIPPJK1 11 17 1 17 1 17 1 17 

NDATA 
7 
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A complete INLETT specification requires six or more additional lines (defining at least 3 
points on the inlet, data, distribution ) following the INLETT boundary data file specification 
line. Failure to properly specify the data in these additional lines is a common INLETT 
specification error. 

Description 

The INLETT statement specifies that a turbomachinery-based radially varying inflow 
boundary condition is to be applied to the mesh surface specified by LFACEl on the block 
specified by LBLOCK1. The INLETT boundary condition was specifically designed as 
an inflow boundary procedure for axial and mixed flow turbomachinery geometries (radial 
flow turbomacliinery inflow boundaries may be specified by the INLETR boundary condi- 
tion). As such, the INLETT boundary procedure is only valid on mesh systems employing 
the cylindrical solution algorithm (see the description of the input variable FCART). The 
INLETT procedure utilizes a Riemann invariant formulation to compute inflow velocities 
based on a specified radial variation in flow properties (upstream reservoir total pressure, 
total temperature, radial flow angle, and circumferential flow angle). Included in the IN- 
LETT procedure is a special correction scheme which forces the flow to pass into the flow 
domain. In other words, if the computed velocities result in a local outflow at the INLETT 
boundary, no matter how small the magnitude of the outflow, the velocities are reset to 
zero at that point. This boundary condition requires the specification of additional data, as 
shown in the boundary data format descriptor above. The first additional line following the 
INLETT specification is assumed to be a label and may contain any information; however, 
for consistency it is recommended that the label NDATA be used. The line following the 
NDATA label contains the number of radial data points which will be used to specify the 
desired radial variation of properties at the inflow boundary. At least 3 radial data locations 
must be specified to use the INLETT boundary condition. The third line following the 
INLETT specifier is again a label which outlines the variables RAD, PTOT, TTOT, 
BETAR and BETAT. The remaining NDATA lines contain the numeric information 
which defines the radial variation of the flow properties specified by these variables. The 
variable RAD is the radius (remember, the centerline is the x axis) at which the data 
is specified. This value should be nondimensionalized in the same manner as the mesh is 
nondimensionalized. This implies that the RAD variable, when multiplied by the input 
variable DIAM will result in the true geometric measurement in feet. Due to the interpo- 
lation procedures which will ultimately be performed on the NDATA lines of radial inflow 
data, it is essential that the radial variations be specified from the inner to the outer radius 
in a monotonic (constantly increasing) fashion. The variables PTOT and TTOT represent 
the local upstream reservoir total pressure and total temperature, respectively, used in the 
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INLETT characteristic solution sequence. The value of the PTOT variable is the desired 
normalized upstream total pressure computed as: 


PTOT 


Ptxrtnl.flf sii'fl 


and the value of the TTOT variable is the desired normalized upstream total temperature 
computed as: 


TTOT = 


T to 


ialAf siTf </ 


The variables P r , ; and T rf j are specified by the input variables PREF and TREF. Values 
of PTOT and TTOT <0.0 are not permitted. The variables BETAR and BETAT 
represent the local radial and circumferential flow angles expressed in degrees according to 
the coordinate orientation defined in Figure 3.9. Naturally, poor convergence or solution 


divergence can occur if any of the values of PTOT. TTOT. BETAR. or BETAT suggest 
boundary values which are significantly different from the remainder of the flow field, or if 
the radial variation of these values is excessively large. In cases where this occurs, it is 
recommended that the solution he started with more conservative boundary values, and 
then restarted using the final boundary values. 


Rostrictions/Limitatioiis 


The INLETT boundary condition assumes that the mesh is oriented in such a fashion that 
t he radial coordinate is defined as r - \J y 1 + ~ 2 . For axial flow turbomachinery, this implies 
that the axis of rotation (or the centerline) coincides with the x axis. It is also required 
that the radial-like direction of the mesh bo defined by the j coordinate. Examples of this 
type of mesh system can be found in the chapter defining standard mesh configurations. 
The INLETT boundary specification is restricted to 3-D mesh surfaces (2-D mesh surfaces 
should use the INL2DT boundary specification). 


Common Errors 


• Application of INLETT to a 2-D mesh system. 

• Failure to specify the additional data values NDATA, PTOT, TTOT. BETAR. or 
BETAT. 

• Radial-like direction of the mesh is not the j coordinate. 

• NDATA less than 3. resulting in job termination. 

• BETAR and/or BETAT orientation incorrectly interpreted. 

• RAD. PTOT and/or TTOT improperly normalized. 

• Mesh/geometry not defined with the x axis as the centerline. 
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Radial Flow Angle 



Circumferential Flow Angle 



Figure 3.9: ADPACO 7 INLETT boundary specification flow angle reference 
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INLETX 


Non-Reflecting Steady State Turbomacliiiiery Inflow Boundary 
Condition 


Radius 


Radius 


Radius 



Total 

Temperature 


Radius 



Radial 
Flow Angle 


Mesh Block #1 
(49x17x17) 


Circumferential 
Flow Angle 


Radial Variation of Turbomachinery Inlet 
Flow Variables for Non-reflecting 
Boundary Requires an INLETX Specification 


Flow 



Application 


The INLETX specification is used to impose a non-reflecting turbomachinery inflow bound- 
ary condition with radially varying flow properties. The illustrative graphic above depicts an 
application of the INLETX inflow boundary condition for an H-type mesh for a turboma- 
chinery fan rotor blade passage. The INLETX specification provides the radial variation 
of flow properties at the inflow boundary resulting from experimental conditions, upstream 
blade rows, or other known inlet property variation. This boundary condition has been 
utilized extensively as ail inlet flow specifier for t urbomachinery blade passages and annular 
ducts. 

Boundary Data File Format 


The boundary data file specification for the mesh surface indicated in the illustrative graphic 
for the INLETX boundary condition is given below: 

INLETX 1 1 I IPPJK 1 11 17 1 17 1 17 1 17 

NDATA 
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7 
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A complete INLETX specification requires six or more additional lines (defining at least 
3 points on the inlet data distribution) following the INLETX boundary data file spec- 
ification line. Failure to properly specify the data in these additional lines is a common 
INLETX specificat ion error. 


Description 


The INLETX statement specifies that a non-reflecting turbomachinery-based radially vary- 
ing inflow boundary condition is to be applied to the mesh surface specified by LFACE1 
on the block specified by LBLOCKl. The INLETX boundary condition was specifically 
designed as a non-reflecting inflow boundary procedure for steady state analysis of axial 
and mixed flow turbomachinery geometries (radial flow turbomachinery inflow boundaries 
may be specified by the INLETR boundary condition). As such, the INLETX bound- 
ary procedure is only valid on mesh systems employing the cylindrical solution algorithm 
(see the description of the input variable FCART). The INLETX procedure utilizes a 
characteristic-based flow decomposition to compute inflow velocities based on a specified 
radial variation in flow properties (upstream reservoir total pressure, total temperature, 
radial flow angle, and circumferential flow angle). Due to the non-reflectivc nature of the 
boundary procedure (described in more detail in the final report [21]). the circumferential 
average of the numerical solution at each radial station matches the specifications imposed 
by the INLETX specification (rather than a point by point matching). This feature per- 
mits circmferential variation of flow properties across the boundaries, where other boundary 
procedures do not. This boundary condition requires the specification of additional data, as 
shown in the boundary data format descriptor above. The first additional line following the 
INLETX specification is assumed to be a label and may contain any information; however, 
for consistency it is recommended that the label NDATA be used. The line following the 
NDATA label contains the number of radial data points which will be used to specify the 
desired radial variation of properties at the inflow boundary. At least 3 radial data locations 
must be specified to use the INLETX boundary condition. The third line following the 
INLETX specifier is again a label which outlines the variables RAD, PTOT, TTOT, 
BETAR and BETAT. The remaining NDATA lines contain the numeric information 
which defines the radial variation of the flow properties specified by these variables. The 
variable RAD is the radius (remember, the centerline is the x axis) at which the data 
is specified. This value should be nondimensionalized in the same manner as the mesh is 
nondimensionalized. This implies that the RAD variable, when multiplied by the input 
variable DIAM will result in the true geometric measurement in feet. Due to the interpo- 
lation procedures which will ultimately be performed on the NDATA lines of radial inflow 
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data, it is essential that the radial variations be specified from the inner to the outer radius 
in a monotonic (constantly increasing) fashion. The variables PTOT and TTOT represent 
the local upstream reservoir total pressure and total temperature, respectively, used in the 
INLETX characteristic solution sequence. The value of the PTOT variable is the desired 
normalized upstream total pressure computed as: 


PTOT = 


l total sired 


P 




and the value of the TTOT variable is the desired normalized upstream total temperature 
computed as: 


7 I () 1 ^ total,df sir'f tl 

T >;f 

Tlio variables l\ f j and I,,j are specified by the input variables PREF and TREF. Values 
of PTOT and TTOT <0.0 are not permitted. The variables BETAR and BETAT 
represent the local radial and circumferential flow angles expressed in degrees according to 
the coordinate orientation defined in Figure T9. Naturally, poor convergence or solution 
divergence can occur if any of the values of PTOT. TTOT. BETAR. or BETAT suggest 
boundary values which are significantly different from the remainder of the flowfield. or if 
the radial variation of these values is excessively large. In such cases, il is recommended 
that the solution be started with more conservative boundary values, and then restarted 
using the final boundary values. 


Rcstrictions/Limitations 

The INLETX boundary condition assumes that the mesh is oriented in such a fashion that 
the radial coordinate is defined as r = \fip + c 2 . For axial flow turbomachinery, t his implies 
that the axis of rotation (or the centerline) coincides with the .r axis. It is also required 
that the radial-like direction of the mesh be defined by the j coordinate. This implies 
that INLETX can only be applied to either constant / or constant k index mesh surfaces. 
INLETX is only valid for steady state solutions (the INLETN boundary procedure is 
available for time-dependent non-reflecting inflow boundaries). 


Common Errors 


• Application of INLETX to a Cartesian mesh solution. 

• Failure to specify the additional data values NDATA, PTOT. TTOT. BETAR. or 
BETAT. 

• Radial-like direction of the mesh is not the j coordinate. 

• Application of INLETX to a constant j mesh surface. 

• NDATA less than A. resulting in job termination. 

• BETAR and/or BETAT orientation incorrectly interpreted. 
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RAD, PTOT and/or TTOT improperly normalized. 
Mesh/geometry not defined with the .r axis as the centerline. 
Application of INLETX for a time-dependent solution. 
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KIL2D 


2-D Solution Kill Routine 


2-D Mesh Block #1 Predicted Mach 

<93x51x1) Number Contours 



Application 


The KIL2D keyword is a tool to effectively neutralize or “kill" the time-marching solution 
over a. segmenl of the computational domain for a two-dimensional mesh. The example 
graphic above illustrates a single block 2-D mesh system used to predict the flow through a 
converging/diverging nozzle system with a square-edged obstruction. Rather than construct 
a multiple block mesh system to treat this case (whereby the obstruction is essentially 
gridded as block boundaries), the KIL2D specification is used to neutralize the advancing 
solution within the obstruction, and boundary conditions are applied along the surface of 
the obstruction to predict this flow. 


Boundary Data File Format 


The boundary data file specification for the mesh interface indicated in the illustrative 

graphic for the KIL2D boundary condition is given below: 

KIL2D 1 1 I I M M L L 40 60 21 31 1 2 21 31 1 2 

LSTART LEND 
40 60 

Note that a complete KIL2D specification requires two additional lines following the 
KIL2D boundary data file specification line. Failure to properly specify the data in these 
additional lines is a common KIL2D specification error. 
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Description 


In cases where a portion of a 2-D mesh does not represent a valid flow region, the KIL2D 
specification can be used, in conjunction with boundary conditions specified about the 
region to be "killed", to effectively remove a portion of a given mesh block from the com- 
putational domain. An example of this technique is illustrated in the illustrative graphic 
above. The figure depicts a single block mesh for the flow through a simple nozzle. Suppose 
that for whatever reason, the user wished to remove an internal rectangular portion of t he 
mesh (as if there were an obstruction placed in the flowpath). This could be accomplished 
by subdividing the original mesh into several smaller pieces, and applying the appropriate 
boundary conditions along the outer boundaries of each block. This same configuration 
could also be modeled using the original mesh by invoking the KIL2D specification for the 
points inside the obstruction, followed by an application of the proper boundary specifica- 
tions along the obstruction internally on the single-block mesh. This boundary condition 
(although really, this is more than a boundary condition) requires the specification of ad- 
ditional data, as shown in the format descriptor above. The variable following the label 
LSTART indicates the starting index of the LFACEl coordinate direction (in the ex- 
ample above, this would be the I coordinate direction) for the region to be "killed". The 
variable following the label LEND indicates the final index in the LFACEl coordinate 
direction (again, the I coordinate in the example above) for the region to be "killed". The 
remaining coordinate indices for the region to be “killed" are determined by the variables 
MlLIMl, M1LIM2 for the J coordinate direction and N1LIM1, and N1LIM2 for the 
K coordinate direction. The additional specification of the LSTART, LEND variables 
imply that the variables LlLIM, L2LIM are not used in this specification. The KIL2D 
routine factions by constantly resetting the flow variables inside the region to be killed to 
the initial values specified by the RMACH input variable. So, in effect, the solution is 
still being performed in the region to be killed, but the updated results are constantly reset 
to a uniform flow value. This routine is not without drawbacks. First of all, although the 
mesh points are effectively neutralized by the KIL2D specification, other routines such as 
the residual smoothing algorithm are unaltered, and under certain circumstances, this may 
cause poor convergence. It is also possible that divergence may occur within the "killed" 
cells in spite of the resetting procedure. The best advice is to manipulate block structures 
to eliminate the need for the use of the KIL2D routine, but the user should be aware that 
under dire circumstances this facility is available. The KILL specification should be given 
prior to any other boundary conditions to avoid “wiping out" previously specified boundary 
specifications. 


Restrictions /Limitations 


The KIL2D boundary specification is restricted to 2-D mesh surfaces (3-D mesh surfaces 
should use the KILL boundary specification). 


Common Errors 


• Application of KIL2D to a 3-1) mesh system. 
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• Poor convergence due to residual smoothing across a ‘'killed' region (The residual 
smoothing operator can be turned off through the RESID input variable, although 
the time step must be restricted (see variable CFL) to maintain numerical stability). 

• Failure to specify tbe additional data values LSTART, LEND. 
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KILL 

Solution Kill Routine 


Mesh Block #1 
(93x25x17) 



Requires a KILL Specification 

Application 

The KILL keyword is a tool to effectively neutralize or ’ L kiir the time-marching solution 
over a segment of the computational domain for a three-dimensional mesh. The example 
graphic above illustrates a single block 3-D O-type mesh system used to predict the flow 
through a turbomachinery compressor rotor blade passage with a surface-mounted square- 
edged obstruction. Rather than construct a multiple block mesh system to treat this case 
(whereby the obstruction is essentially gridded as block boundaries), the KILL specification 
is used to neutralize the advancing solution within the obstruction, and boundary conditions 
are applied along the surface of the obstruction to predict this flow. 


Boundary Data File Format 
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The boundary data file specification for the mesh system indicated in the illustrative graphic 
for the KILL boundary condition is given below: 

KILL 1 1 I I P P L L 49 49 1 19 1 5 1 19 1 5 

LSTART LEND 
49 51 

KILL 1 1 I I P P L L 49 49 19 21 1 5 19 21 1 5 

LSTART LEND 
49 52 

Note t hat a complete KILL specification requires two additional lines following the KILL 
boundary data file specification line. Failure to properly specify the data in these additional 
lines is a common KILL specification error. 


Description 


In cases where a portion of a d-l) mesh does not represent, a valid flow region, the KILL spec- 
ification can be used, in conjunction with boundary conditions specified about the region to 
be "killed", to effectively remove a portion of a given mesh block from the computational 
domain. An example of this technique is illustrated in the illustrative graphic above. The 
figure depicts a. single mesh block for the flow through a high speed rotor passage upon which 
surface instrumentation is mounted. The blockage associated with the surface instrumenta- 
tion is incorporated into the solution through the application of the appropriate boundary 
conditions on the surface of the instrumentation, and by applying the KILL procedure to 
negate the flow variables of the cells within the instrumental ion itself. It should be noted 
that this effect could be accomplished by subdividing the original mesh into several smaller 
pieces, and applying the appropriate boundary conditions along the outer boundaries of 
each block. This boundary condition (although really, this is more than a boundary condi- 
tion) requires the specification of additional data, as shown in the format descriptor above. 
The variable following the label LSTART indicates the starting index in the LFACE1 
coordinate direction (in the example above, this would be the I coordinate direction) for 
the region to be "killed". The variable following the label LEND indicates the final index 
in the LFACE1 coordinate direction (again, the I coordinate in the example above) for 
the region to be "killed". The remaining coordinate indices for the region to be "killed" 
are determined by the variables M1LIM1, M1LIM2 for the J coordinate direction and 
N1LIM1. and N1LIM2 for the K coordinate direction. The additional specification of 
the LSTART, LEND variables imply that the variables LlLIM, L2LIM are not used 
in this specification. The KILL routine factions by constantly resetting the flow variables 
inside the region to be killed to the initial values specified by the RMACH input variable. 
So. in effect, the solution is still being performed in the region to be killed, but the updated 
results are constantly reset to a uniform flow value. This routine is not without drawbacks. 
First of all. alt hough the mesh points are effectively neutralized by the KILL specification, 
other routines such as the residual smoothing algorithm are unaltered, and under certain 
circumstances, this may cause poor convergence. It is also possible that divergence may 
occur within the "killed" cells in spite of the resetting procedure. The best advice is to 
manipulate block structures to eliminate the need for the use of the KILL routine, but the 
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user should be aware that under dire circumstances this facility is available. The KILL 
specification should be given prior to any other boundary conditions to avoid “wiping out" 
previously specified boundary specifications. 


Restrictions/Limitations 


The KILL boundary specification is not restricted to 3-1) mesh surfaces (although for 
consistency, 2-1) mesh surfaces may use the KIL2D boundary specification). 


Common Errors 


• Application of KILL to a 2-1) mesh system. 

• Poor convergence due to residual smoothing across a “killed 1 " region (The residual 
smoothing operator can be turned off through the RESID input variable, although 
the time step must be restricted (see variable CFL) to maintain numerical stability). 

• Failure to specify the additional data values LSTART, LEND. 
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LAMSS 

Porous Solid Surface V iscous No-Slip Boundary Condition 


Blade Surface Porous 

Boundary Requires a Mesh Block #1 



Boundary Specification 

Application 

The LAMSS specification is used to impose a porous injection, no-slip boundary condition 
for solid surfaces used in a viscous flow solution. The graphic above illustrates a 3-1) body- 
centered O-type mesh system for a turbine vane cascade. The LAMSS specification is 
used to simulate the effects of a fine array of discrete cooling holes (porous injection) which 
are too small to be individually gridded. The LAMSS provides a “smeared out" normal 
injection which essentially simulates the global effects of the individual cooling sites. 

Boundary Data File Format 

The boundary data file specifications for the hub and blade surfaces in the application de- 
scribed above and indicated in the illustrative graphic for the LAMSS boundary condition 
are given below: 

LAMSS 1 1 K K P P I K 1 1 1 151 1 11 1 151 1 11 

PT TT RPMLOC TWALL ARATIQ 

1.1 0.70 0.0 0.00 0.10 

Note that a complete LAMSS specification requires two additional lines following the 



172 


LA MSS - ADPAC'07 Boundary Data File Specifications 


LAMSS boundary data file specification line. Failure to properly specify the data in these 
additional lines is a common LAMSS specification error. 


Description 


The LAMSS statement specifies that a solid surface viscous (no-slip) boundary condi- 
tion is to be applied to the mesh surface specified by LFACE1 on the block specified by 
LBLOCK1. The LAMSS boundary condition may be applied to eit her a rotating or non- 
rotating surface and may indicate a rotational speed which is different than the rotational 
speed of the mesh (RPM) to which the boundary condition is applied (the most common 
example of this type of application is a mesh embedded in a rotating blade passage with 
an endwall which is non-rotating). This boundary condition requires the specification of 
additional data, as shown in the boundary data format descriptor above. The first addi- 
tional line following the LAMSS specification is assumed to be a label and may contain any 
information; however, for consistency it is recommended that the labels PTOT. TTOT. 
RPMLOC, TWALL, and ARATIO be used. The next line contains the values imposed 
for the variables PTOT. TTOT. RPMLOC. TWALL, and ARATIO. The value of the 
PTOT and TTOT variables represent the total pressure and total temperature of the 
injected flow. These variables are defined as: 


( Ptotnl ) non — dim f nsional 

(T t C) tal ) not} — di in e n s i o n a l 


P | total 

Prff 

TloUd 

Pr'f 


The value of the RPMWALL variable is the desired solid wall dimensional rotational 
speed in revolutions per minute. This value is sign dependent and follows the orientation 
for rotation as described in Figure 3.10. The variable TWALL determines which type 
of temperature condition is applied to the surface. If TWALL=0.0, an adiabatic wall is 
assumed. For TWALL>0.0, a constant temperature surface with a nondimensional wall 
temperature of TWALL defined as: 


. ' i ■ . * ivutl 

l * trail /non — dimensional — 

1 r< f 

is imposed. (Here T r ej is the reference temperature imposed by the input file variable 
TREF. A value of TWALL<0.0 is not permitted. Naturally, poor convergence or solution 
divergence can occur if RPMWALL or TWALL suggest boundary values which are sig- 
nificantly different from the remainder of the fiowfield. In such cases where this occurs, it 
is recommended that the solution be started with more conservative boundary values, and 
then restarted using the final boundary values. Finally, the value of the variable ARATIO 
represents the geometric “porosity" of the surface in the form of the ratio of open ( injection ) 
surface area to total surface area for the boundary segment being defined. In other words, 
if the porous surface has an injection area of .01 square inch per square inch of total surface, 
then ARATIO would be 0.01. ARATIO values less than zero or greater than 1.0 are not 
permitted. 
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Restrictions/Limitations 


The boundary rotational speed imposed by the LAMSS boundary condition can only be 
nonzero when using the cylindrical coordinate solution algorithm in the ADPA('()7 code. 
When using the (’artesian coordinate solution algorithm FCART and/or FCARB— 1.0. 
the boundary rotational speed must be zero (RPMWALL= 0.0 when FCART or FCARB 
1.0). Refer to the Chapter on input file parameters for a description of TREF. RPM. 
FCARB. and FCART. The injection process modeled by LAMSS is always normal to 
the local surface topography. Arbitrary injection angle specification is not currently possi- 
ble. 


Common Errors 


• Incorrect sign for value of boundary rotational speed RPMWALL. 

• Attempt to utilize a nonzero boundary rotational speed with the Cartesian coordinate 
solution algorithm. 

• ARATIO value less than 0.0 or greater than 1.0. 

• PTOT value significantly different than freest ream. 

• TTOT value significantly different than freest ream. 

• TWALL value significantly different than freest ream. 
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MBCAVG 

Multiple Block Circumferential Averaging Routine for Multiple 
Blade Row Turbomachines 


Mesh Block #1 
(81x6x7) 


Mesh Block #2 
(81x6x7) 




Mixing Plane Interface Between Adjacent 
Blade Rows of Multistage Turbomachinery 
Utilize the MBCAVG Specification 


Application 


The MBCAVG specification is used in applications involving neighboring relatively rotat- 
ing blade rows which may consist of one or more mesh blocks. The MBCAV G specification 
permits time-averaged interconnection between these adjacent, blade row local mesh sys- 
tems based on the “mixing plane" approximation discussed in Chapter '2.0. The sample 
graphic illustrates the application of the MBCAVG boundary condition for the case of a 
single stage turbine, whereby a single mesh block is used to represent a single blade passage 
for each blade row in the turbine stage, and the MBCAVG boundary routine is used to 
perform the mixing plane (circumferential/ time-averaged) coupling of the relatively rotating 
blade rows. 
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Boundary Data File Format: 


The boundary data file specifications for the mesh interfaces indicated in the illustrative 
graphic for the MBCAVG boundary condition are given below. Note that block 1 requires 


multiple s 

pecifications 

due to 1 1 

le location of the O-grid cut line 




MBCAVG 

1 2 K 

K M M 

I J 

7 7 1 

6 1 

6 36 

46 1 

6 

NSEGS 









i 

LBL0CK2B 

LFACE2B 

LDIR2B 

L2LIMB 

M2LIM1B 

M2LIM2B 

N2LIM1B 

N2LIM2B 


2 

K 

M 

7 

36 

46 

1 

6 


MBCAVG 

1 2 K 

K M M 

I J 

7 7 76 

81 1 

6 36 

46 1 

6 

NSEGS 









1 

LBL0CK2B 

LFACE2B 

LDIR2B 

L2LIMB 

M2LIM1B 

M2LIM2B 

N2LIM1B 

N2LIM2B 


2 

K 

M 

7 

36 

46 

1 

6 


MBCAVG 

2 1 K 

K M M 

I J 

7 7 36 

46 1 

6 1 

6 1 

6 

NSEGS 

o 









z 

LBL0CK2B 

LFACE2B 

LDIR2B 

L2LIMB 

M2LIM1B 

M2LIM2B 

N2LIM1B 

N2LIM2B 


1 

K 

M 

7 

1 

6 

1 

6 


1 

K 

M 

7 

76 

81 

1 

6 



Note that a. complete MBCAVG specification generally requires at least two MBCAVG 
statement lines in the boundary data file for each mesh interface. In the example above, 
the first two specifications provide the interblock communication for block I from block 2. 
and the third specification provides the communication for block 2 from block 1. It is a 
common error to underspecify an MBCAVG boundary by only providing a single line per 
interface. 


Description: 


The MBCAVG specification provides a "circumferential mixing plane" mesh block com- 
munication scheme for steady state ( time- averaged ) analysis of multiple blade row turboma- 
chines. The MBCAVG operator permits the specification of multiple neighboring blocks 
upon which the circumferential averaging is applied to provide boundary data for the cur- 
rent block of interest. This multiple block averaging scheme permits the use of MBCAVG 
for body-centered mesh systems (see the illustrative graphic above) and also for multiple 
blade passage representations of neighboring blade rows. Due to the complex nature of the 
circumferential averaging operator, this boundary condition is restricted to specific mesh 
configurations. The following chart describes the permitted mesh configurations for the 
MBCAVG specification: 


MBCAVG Boundary Specification Mesh Coordinate Restrictions 


LFACE1 


LFACE2 


Circumferential Grids Must be 
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(Block #1 
Face) 


(Block #2 
Face) 


Coordinate 

Direction 


Aligned in this 
Coordinate 


I 

J 

K 


I or K K or I 

J only K 

I or K K or I 


J 

I 

J 


A second mesh restriction is that the interface separating two adjacent blade rows must be 
a surface of revolution, and that meshes along this interface have common axial and radial 
grid distributions. This restriction simplifies the averaging scheme provided by the 

MBCAVG specification. 

The MBCAVG boundary condition requires the specification of additional data, as shown 
in the format descriptor above. The variable following the label NSEGS defines the num- 
ber of neighboring mesh block surfaces from which the circumferentially averaged data is 
obtained. In the illustrative graphic above, this value is simply 1 for the upstream inter- 
blade row boundaries, but is 2 for the downstream inter-blade row boundary because of the 
fact that the matching boundary of the upstream blade row is composed of two distinct 
mesh segments even though it is taken from a single mesh block. The next line follow- 
ing the NSEGS variable is a label indicating the variables which must be input for each 
of the NSEGS segments in the mixing plane. The variables LBLOCK2B, LFACE2B. 
LDIR2B, L2LIMB. M2LIM1B. M2LIM2B, N2LIM1B, and N2LIM2B represent the 
values of LBLOCK2, LFACE2. LDIR2, L2LIM, M2LIM1, M2LIM2, N2LIM1. and 
N2LIM2 (see the beginning of this section for an explanation of these variables) for each 
of the individual NSEGS segments used in the mixing plane construction. The segments 
may be specified in any order. 


Restrictions/Limitations 


The MBCAVG boundary specification is restricted to mesh interfaces which lie on a com- 
moil surface (no significant overlap), and have common axial and radial mesh coordinates. 
The mesh must obey the coordinate restrictions outlined in the description above. 


Common Errors 


• Failure to provide 2 or more MBCAVG statements for each inter-blade row interface. 

• Incorrectly specified or misaligned extents of boundary regions (values of M1LIM1, 
M1LIM2, NlLIMl, N1LIM2, M2LIM1B, M2LIM2B, N2LIM1B, N2LIM2B 
do not correctly define the interface extents on blocks LBLOCKl and LBLOCK2B) 

• Meshes do not obey the mesh coordinate restrictions listed in the description above. 

• Meshes have dissimilar axial and radial coordinates at t he interface. 

• Application of MBCAVG to mesh interfaces which do not share a common surface, 
or which have excess overlap. 
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• Application of MBCAVG to Cartesian solution mesh system 
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PATCH 


Contiguous Mesh Block Interface Patching Scheme 



Spatially Periodic Mesh 
Block Interface 
on Grid 1 Requires a 
PATCH Specification 


Self-connected Mesh Block 
Interface (O-type mesh) 
on Grid t Requires a 
PATCH Specification 


Application 


The PATCH specification is used in any application involving neighboring mesh blocks with 
a contiguous (common mesh points) interface. The graphic above illustrates a PATCH con- 
nection between mesh blocks in a combination 0-H mesh system for a turbine vane cascade. 
The PATCH boundary specification is used to provide block-to-block communication be- 
tween mesh blocks #1 and #2, and mesh blocks #1 and #3. as well as providing periodic 
flow boundary conditions for blocks #1. #2, and #3. In addition, the PATCH routine 
is used to provide aerodynamic communication across the O-mesh slit for mesh block #1. 
The PATCH boundary condition is perhaps the most common specification resulting from 
the use of the multiple blocked mesh capabilities of the ADPAC07 code. 


Boundary Data File Format 


The boundary data (ile specifications for the mesh interface indicated in the illustrative 
graphic for the PATCH boundary condition are given below: 


PATCH 

1 

1 

K 

K 

M 

M 

i 

J 

11 

11 

6 

71 

1 

17 

146 

81 

1 

17 

Blk 

#1 

Per 

PATCH 

1 

1 

K 

K 

M 

M 

i 

J 

11 

11 

81 

146 

1 

17 

71 

6 

1 

17 

Blk 

#1 

Per 

PATCH 

2 

2 

K 

K 

P 

M 

i 

J 

1 

11 

1 

17 

1 

17 

1 

17 

1 

17 

Blk 

#2 

Per 
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PATCH 

2 

2 

K 

K 

M 

P 

I 

J 

11 

1 

1 

17 

1 

17 

1 

17 

1 

17 

Blk #2 Per 

PATCH 

3 

3 

K 

K 

P 

M 

I 

J 

1 

11 

1 

17 

1 

17 

1 

17 

1 

17 

Blk #3 Per 

PATCH 

3 

3 

K 

K 

M 

P 

I 

J 

11 

1 

1 

17 

1 

17 

1 

17 

1 

17 

Blk #3 Per 

PATCH 

1 

1 

I 

I 

M 

P 

J 

K 

151 

1 

1 

17 

1 

11 

1 

17 

1 

11 

Blk #1 0-Grid 

PATCH 

1 

1 

I 

I 

M 

P 

J 

K 

1 

151 

1 

17 

1 

11 

1 

17 

1 

11 

Blk #1 0-Grid 

PATCH 

1 

2 

K 

I 

M 

M 

J 

I 

11 

17 

71 

81 

1 

17 

1 

17 

1 

11 

Blks #l-#2 

PATCH 

2 

1 

I 

K 

M 

M 

K 

J 

17 

11 

1 

17 

1 

11 

71 

81 

1 

17 

Blks #l-#2 

PATCH 

1 

3 

K 

I 

M 

P 

J 

I 

11 

1 

1 

6 

1 

17 

1 

17 

6 

1 

Blks #l-#3 

PATCH 

3 

1 

I 

K 

P 

M 

K 

J 

1 

11 

1 

17 

1 

6 

6 

1 

1 

17 

Blks #l-#3 

PATCH 

1 

3 

K 

I 

M 

P 

J 

I 

11 

1 

146 

151 

1 

17 

1 

17 

11 

6 

Blks #l-#3 

PATCH 

3 

1 

I 

K 

P 

M 

K 

J 

1 

11 

1 

17 

6 

11 

151 

146 

1 

17 

Blks #l-#3 


Not e that a complete PATCH specification generally requires two PATCH statement 
lines in the boundary data file. For any two grid blocks (1 and 2 for example), the first 
specification provides the interblock communication for block 1 from block 2. and the second 
specification provides the communication for block 2 from block 1. It is a common error to 
underspecify a PATCH boundary by only providing a single line per interface. 


Description 


The PATCH statement is utilized to provide direct block to block communication between 
mesh blocks with contiguous grid points. This is perhaps the most common, and most 
useful of the boundary condition specifications, and therefore, a lengthy discussion is given 
to complete this description. For many complicated geometries requiring a multiple block 
mesh system, a common approach is to generate mesh systems with coincident mesh points 
along all. or at least part of the mesh block interfaces. This property is henceforth referred 
to as a contiguous mesh block interface (coincident mesh points). By default, the boundary 
condition specification must have a one to one correspondence between mesh points in block 
LBLOCK1 and mesh points in block LBLOCK2. This type of boundary is particularly 
effective 1 in the finite- volume flow solver due to the fact that local and global conservation 
of the flow variables can be accomplished without special treatment, by direct substitution 
of the neighboring block flow variables into the phantom cells of the block of interest. The 
PATCH boundary condition performs this direct substitution between blocks to provide 
an aerodynamic communication between neighboring blocks with a contiguous interface. 
A PATCH specification can also be imposed connecting a block to itself. In fact, this is 
the manner by which spatial periodicity is enforced in many cases, including the Standard 
Configurations described in Chapter 5. The PATCH boundary condition requires no addi- 
tional data beyond the initial specification line, but does require the proper specification of 
the variables LSPEC1 and LSPEC2. For boundary conditions involving more than one 
mesh block (such as PATCH), it is possible that the connection between blocks may in- 
volve communication between different grid surfaces (for example, an /=consta.nt mesh face 
in LBLOCK1 connects to a j=constant mesh face in LBLOCK2) and that the remain- 
ing indices in block LBLOCK2 correspond to different coordinates in block LBLOCKl. 
The specification of the variables LSPEC1, LSPEC2 serve to eliminate any confusion 
between contiguous boundary patches involving dissimilar mesh coordinates. In every case, 
when a particular coordinate direction is specified by the variable LFACEl, the remain- 
ing coordinate indices defining the extent of the patch on LFACEl are specified in their 
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“natural” (*, j, k) order. For example, if LFACE1 is an i=constant mesh surface, then the 
variables M1LIM1, M1LIM2 control the indices in the j coordinate direction and the 
variables N1LIM1, N1LIM2 control the indices in the k coordinate direction. Similarly, 
if LFACE2 is a Ar=constant mesh surface, then the variables M2LIM1, M2LIM2 control 
the indices in the / coordinate direction and the variables N2LIM1, N2LIM2 control the 
indices in the j coordinate direction, and so on. Now, in order to relate the coordinate 
indices in block LBLOCK2 with the indices specified in block LBLOCK1. the special 
terms LSPEC1 and LSPEC2 are utilized. The variables LSPEC1 and LSPEC2 should 
be defined as either I, J, or K, based on the connection scheme between the two blocks. 
The LSPECl variable should define the coordinate direction in block LBLOCK1 which 
corresponds to the first, remaining coordinate in block LBLOCK2 (whose range is defined 
by M2LIM1, M2LIM2), and the LSPEC2 variable should define the coordinate direc- 
tion in block LBLOCK1 which corresponds to the second remaining coordinate in block 
LBLOCK2 (whose range is defined by N2LIM1, N2LIM2). The PATCH specification 
may also be used for two-dimensional meshes as long as the third coordinate direction (k) 
limits N1LIM1. N1LIM2, and N2LIM1, N2LIM2 are “IT and T2'\ respectively (2-D 
patches are specified as if the mesh were actually 2 cells deep in the k direction). 


Restrictions /Limitations 


The PATCH boundary specification is restricted to mesh interfaces which have a one to 
one mesh point correspondance. To maintain the conservative property of the governing 
equations, the PATCH routine assumes that the mesh points between the 2 blocks of 
interest are either contiguous, or share a spatially periodic relationship, and it is left to the 
user to verify that this is so. 


Common Errors 


• Failure to provide 2 PATCH statements for each interface. 

• Incorrectly specified or misaligned extents of boundary regions (values of M1LIM1, 
M1LIM2, N1LIM1, N1LIM2, M2LIM1, M2LIM2, N2LIM1, N2LIM2 do not 
correctly define the interface extents on blocks LBLOCK1 and LBLOCK2). 

• Incorrectly specified block coordinate direction relationships (values of LSPECl, 
LSPEC2 do not correctly define the coordinate connection scheme between block 

LBLOCK1 and block LBLOCK2). 

• PATCH boundary specification for a periodic boundary is applied to a nonperiodic 
mesh. 

• PATCH boundary specification applied to a spatially periodic Cartesian geometry 
using the cylindrical coordinate solution scheme or vice versa (results in incorrect 
spatial periodicity relationships) The PATCH boundary specifications for ( artesian 
geometries must use the ( artesian solution algorithm in ADPAC01 (see input variable 
FCART). 
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PINT 

Non- Contiguous Mesh Block Interface Patching Scheme 

Mesh Block #2 



Non-Contiguous Mesh Block Interface Between i 

Grids 1 and 2 Requires a PINT Specification j 

(illustrated in Boundary Data File Format 
statements below) 

Application 

The PINT specification is used in any application involving neighboring niesli blocks which 
share a common mat ing surface (eit her contiguous or non-contiguous). The example graphic 
above illustrates a two-dimensional plane of a two block CD mesh system used to predict the 
flow through a converging/diverging nozzle. The mesh points at the interface between the 
two grids (near the nozzle throat) are noncontiguous, and therefore, the PINT specification 
is used to provide communication between the adjacent mesh blocks. 

Boundary Data File Format 

The boundary data file specifications for the mesh interface indicated in the illustrative 
graphic for the PINT boundary condition are given below: 

PINT 1 2 I I M P L L 51 1 1 11 1 45 1 11 1 51 

PINT 2 1 I I P M L L 1 51 1 11 1 51 1 11 1 45 

Note that a complete PINT specification generally requires two PINT statement lines in 
the boundary data file. In the example above, the first specification provides the interblock 
communication for block 1 from block 2. and the second specification provides the commu- 
nication for block 2 from block 1. It is a common error to underspecify a PINT boundary 
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by only providing a single line per interface. 

Description 


The PINT boundary statement provides a means for block to block communication for cases 
involving neighboring meshes which share a common surface, but not necessarily common 
grid points along a block boundary (meshes with contiguous mesh points should use the 
PATCH boundary specification, meshes with contiguous points in one coordinate direc- 
tion should use the BCINT1 boundary specification ). The PINT specification instructs 
the ADPAC07 code to perform a weighted interpolation to determine the appropriate flow 
variables for the phantom cells, based on the non-contiguous data structure of the neigh- 
boring mesh. An example of this type of boundary is given in the illustrative graphic. The 
bounding surfaces of each block should lie on a common surface (no significant overlap). 
The interpolation scheme used in the PINT specification is not conservative, and therefore 
the solution accuracy can be degraded by this procedure. During code execution, the first 
time the PINT specification is encountered, the code initiates a search to determine the 
interpolation stencil for the given array of points in block LBLOCK1 based on the data 
in block LBLOCK2. This stencil is then saved to eliminate the search routine at every 
application of PINT. In order to provide storage for the interpolation stencil information, 
a separate array system based on the dimensioning parameter NRAINT (see Section 3.3 
) is utilized. The PINT boundary condition requires no additional data beyond the initial 
specification line, but does require some extra care when used. The primary precaution 
is that the PINT procedure is based entirely on a simplified interpolation scheme, and 
hence, does not maintain either global or local conservation of flow variables across the 
mesh interface. 


Restrictions/Limitations 


The PINT boundary specification is restricted to mesh interfaces which lie on a com- 
mon surface (no significant overlap). The PINT procedure is only applicable to 3-D mesh 
systems. PINT can not be used across multiple processors in a parallel computing envi- 
ronment. 


Common Errors 


• Failure to provide 2 PINT statements for each interface. 

• Incorrectly specified or misaligned extents of boundary regions (values of M1LIM1, 
M1LIM2, N1LIM1, N1LIM2, M2LIM1, M2LIM2, N2LIM1, N2LIM2 do not 
correctly define the interface extents on blocks LBLOCK1 and LBLOCK2). 

• Attempt to use PINT for a periodic boundary (no special spatial periodicity arrange- 
ment is available in PINT. 

• Attempt to use PINT on a 2-D mesh block. 
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• Failure to provide enough storage for the PINT interpolation stencils via t he NRAINT 
parameter. 

• Application of PINT to mesh interfaces which do not share a common surface, or 
which have excess overlap. 

• Attempt to use PINT across multiple processors in a parallel computing environment . 
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SS2DIN 


2-D Solid Surface Inviscicl No Through- Flow Boundary Condi- 
tion 


L_ 


2-D Mesh Block #1 
(193x13x1) 


Blade Surface No Through-Flow 
Boundary Requires an 
SS2DIN Specification 
(Illustrated in Boundary 
Data File Format Statement 
Below) 



Application 


The SS2DIN specification is used to impose a no through-flow inviscid solid surface con- 
dition for any solid surface in a 2-D solution. The illustrative graphic above depicts a 2-D 
(’-type Cartesian mesh system for a planar turbine airfoil cascade. The SS2DIN descriptor 
is applied to denote the airfoil no through -flow surface boundary condition. Applications for 
2-D turbmomachiuery calculations are typically the endwall (axisymmetric flow) or airfoil 
(Cartesian flow) surfaces. 


Boundary Data File Format 


The boundary data file specification for the mesh boundary indicated in the illustrative 
graphic for the SS2DIN boundary condition is given below: 

SS2DIN 1 1 J J P P I K 1 1 65 161 1 2 65 161 1 2 

No additional data beyond t he boundary data file descriptor is required. 
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Description 


The SS2DIN statement specifies that a solid surface in viscid (no through-flow) bound- 
ary condition is to be applied to the mesh surface specified by LFACEl on the block 
specified by LBLOCK1. The SS2DIN procedure is the 2-1) equivalent of SSIN. The 
SS2DIN boundary condition may be applied to either rotating or non-rotating surfaces. 
The rotational speed of the boundary is irrelevant for an inviscid surface on a properly de- 
fined mesh (either the boundary rotates with the mesh. or. in the case where the rotational 
speeds of the mesh and boundary differ, there is no difference in the a plica t ion of an inviscid 
surface boundary condition). SS2DIN may be applied for either cylindrical or ('artesian 
solution meshes (see the description of the input variable FCART). The SS2DIN algo- 
rithm imposes no flow normal to the local mesh surface, but permits tangential velocity 
components at the boundary. The current SS2DIN algorithm is based on a loose speci- 
fication of the local static pressure ( ^ = 0) and is known to introduce some nonphysical 
loss. However, it has been the authors experience that this formulation provides the best 
mix of accuracy and reliability for most applications. It should be noted t hat the SS2DIN 
boundary condit ion is also very useful as a method of imposing a symmet ry plane in a solu- 
tion for geometries which possess spatial symmetry. Naturally, the mesh must be generated 
in a manner which represents this spatial symmetry as well. 


Restrictions/Limitations 


The SS2DIN boundary specification is restricted to 2-1) mesh surfaces (3-1) mesh surfaces 
should use the SSIN boundary specification). 


Common Errors 


• Application of SS2DIN to a 3-D mesh system. 

• Application of SS2DIN as a symmetry plane condition for a mesh which does not 
represent a spatially symmetric geometry. 
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SS2DVI 

2-D Solid Surface Viscous No-Slip Boundary Condition 

X 

y 


Blade Surface No-Slip x 
Boundary Requires an 
SS2DVI Specification 
(Illustrated in Boundary 
Data File Format Statement 
Below) 


Application 

The SS2DVI specification is used to impose a no-slip boundary condition for any solid 
surface used in a 2-D viscous flow solution. The example graphic above illustrates a 2-1) 
(’-type mesh system used to predict the flow through a planar 2-1) turbine vane cascade. 
Applications for 2-D turbmomachinery calculations are typically the endwall surfaces (both 
rotating and non-rotating surfaces) for an axisymmetric 2-D solution or non-rotating solid 
surfaces in Cartesian 2-1) solutions. 

Boundary Data File Format: 

The boundary data file specifications for the mesh interface indicated in the illustrative 
graphic for the SS2DVI boundary condition are given below: 



SS2DVI 1 1 J J P P I K 1 1 65 161 1 2 65 161 1 2 

RPMWALL TWALL 
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0.0 0.0 

Note that a comj)lete SS2DVI specification requires two additional lines following the 
SS2DVI boundary data file specification line. Failure to properly specify the data in these 
additional lines is a common SS2DVI specification error. 


Description 


The SS2DVI statement specifies that a solid surface viscous (no-slip) boundary condi- 
tion is to be applied to the mesh surface specified by LFACEl on the block specified by 
LBLOCKl. The SS2DVI procedure is the 2-1) equivalent of SSVI. The SS2DVI bound- 
ary condition may be applied 1o either a rotating or non-rotating surfaces and may indicate 
a rotational speed which is different than the rotational speed of the mesh (RPM) to which 
the boundary condition is applied. This boundary condition requires the specification of 
additional data, as shown in the boundary data format descriptor above. The first addi- 
tional line following the SS2DVI specification is assumed to be a label and may contain any 
information; however, for consistency it is recommended that the labels RPM WALL and 
TWALL be used. The next line contains the values imposed for the variables RPMWALL 
and TWALL. The value of the RPMWALL variable is the desired solid wall dimensional 
rotational speed in revolutions per minute. This value is sign dependent, and follows the ori- 
entation for rotation as described in Figure 3.10. The variable TWALL determines which 
type of temperature condition is applied to the surface. If TWALL = 0.(). an adiabatic wall 
is assumed. For TWALL>0.0. a constant temperature surface with a nondimensional wall 
temperature of TWALL defined as: 

( ^ trail — dim f nsionn! -i • 

w 

is imposed. (Here T tf j is the reference temperature imposed by the input file variable 
TREF.) A value of TWALLcO.O is not permitted. Naturally, poor convergence or solu- 
tion divergence can occur if RPMWALL or TWALL suggest boundary values which are 
significantly different from the remainder of the flowfield. In such cases where this occurs, 
it is recommended that the solution be started with more conservative boundary values, 
and then restarted using the final boundary values. 


Restriotioiis/Limitatioiis 


The SS2DVI boundary specification is restricted to 2-1) mesh surfaces (3-1) mesh surfaces 
should use the SSVI boundary specification). The boundary rotational speed imposed by 
the SS2DVI boundary condition can only be non-zero when using the cylindrical coordinate 
solution algorithm in the .• 1/) FA C01 code, and may only be applied to axisymmetric 2-1) 
meshes. When using the (’artesian coordinate solution algorithm (FCART= 1.0), the 
boundary rotational speed must lie zero (RPMWALL= 0.0 when FCART= 1.0). Refer 
to the chapter on input file parameters for a description of TREF. RPM. and FCART. 


Common Errors 
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ADPAC Rotational Speed Orientation 

\ ■ 


i 

RPM (-) 1 

ADVR (-) 

RPM (+) ^ 

ADVR (+) 




ADPAC rotation is always about the X axis 


Figure 3.10: AD PA (07 rotational speed orientation illustration 
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• Incorrect sign for value of boundary rotational speed RPMWALL. 

• Attempl to utilize a non-zero boundary rotational speed with the ('artesian coordinate 
solution algorithm. 

• Application of SS2DVI to a .*$-!) mesh system. 
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SSIN 

Solid Surface Inviseid No-Through- Flow Boundary Condition 


Mesh Block #1 
(151x17x11) 



Hub Surface No Through-Flow 
Boundary Requires an 
SSIN Specification 


Application 


The SSIN specification is used to impose a no-through-fiow inviseid solid surface condition 
for any solid surface in a solution. The graphic above illustrates a 3-D body-centered O- 
type mesh system for a turbine vane cascade. For turbomachinery calculations, the SSVI 
specification is normally used to define the blade and endwall surfaces (both rotating and 
non-rotating surfaces may be described). 

Boundary Data File 1 Format 


The boundary data file specification for the mesh boundary indicated in the illustrative 
graphic for the SSIN boundary condition is given below: 


SSIN 1 1 J J P P I K 1 1 1 151 1 11 1 151 1 11 

SSIN 1 1 K K P P I K 1 1 1 151 1 17 1 151 1 17 
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No additional data beyond the boundary data file descriptor is required. 


Description 


The SSIN statement specifies that a solid surface inviscid (no through-flow) boundary 
condition is to be applied to the mesh surface specified by LFACE1 on the block specified 
by LBLOCKl. The SSIN boundary condition may be applied to either rotating or non- 
rotating surface's. The rotational speed of the boundary is irrelevant for an inviscid surface 
on a properly defined mesh (either the boundary rotates with the mesh, or. in the case 
where the rotational speeds of the mesh and boundary differ, there is no difference in the 
application of an inviscid surface boundary condition). The SSIN algorithm imposes no 
flow normal to the local mesh surface, but permits tangential velocity components at the 
boundary. The current SSIN algorithm is based on a loose specificat ion of the local static 
pressure ( ^ = 0) and is known to introduce some nonphysical loss. However, it has been t he 
authors experience that this formulation provides the best mix of accuracy and reliability 
for most applications. It should be noted that the SSIN boundary condition is also very 
useful as a method of imposing a symmetry plane in a solution for geometries which possess 
spatial symmetry. Naturally, the mesh must be generated in a manner which represents 
this spatial symmetry as well. 


Restrirtioiis/Liinitatioiis 

The SSIN boundary specification is restricted to 3-1) mesh surfaces (2-1) mesh surfaces 
should use the SS2DIN boundary specification). 


Common Errors 


• Application of SSIN to a 2-D mesh system. 

• Application of SSIN as a symmetry plane condition for a mesh which does not repre- 
sent a spatially symmetric geometry 
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SSVI 


Solid Surface Viscous No- Slip Boundary Condition 


Mesh Block #1 
(151x17x11) 



Hub Surface No-Slip 
Boundary Requires an 
SSVI Specification 


Application 


The SSVI specification is used to impose a no-slip boundary condition for solid surfaces 
used in a viscous flow solution. The graphic above illustrates a 3-1) body-centered Ci- 
ty pe mesh system for a turbine vane cascade. For turbomachinery calculations, the SSVI 
specification is normally used to define the blade and endwall surfaces (both rotating and 
non-rotating surfaces may be described). 


Boundary Data File Format 


The boundary data file specifications for the hub and blade surfaces in the application 
described above and indicated in the illustrative graphic for the SSVI boundary condition 
are given below: 
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SSVI 1 

1 J 

J 

P 

p 

I 

K 

RPMWALL 

TWALL 






0.0 

0.0 






SSVI 1 

1 K 

K 

P 

p 

I 

K 

RPMWALL 

TWALL 






0.0 

0.0 







1 1 1 151 1 11 1 151 1 11 

1 1 1 151 1 17 1 151 1 17 


Note that a complete SSVI specification requires two additional lines following the SSVI 
boundary data file specification line. Failure to properly specify the data in t hese additional 
lines is a common SSVI specification error. 

Description 


The SSVI statement specifies that a solid surface viscous ( no-slip ) boundary condi- 
tion is to be applied to the mesh surface specified by LFACE1 on the block specified by 
LBLOCK1. The SSVI boundary condition may be applied to either a rotating or non- 
rotating surface and may indicate a rotational speed which is different than the rotational 
speed of the mesh (RPM) to which the boundary condition is applied (the most common 
example of this type of application is a mesh embedded in a rotating blade passage with 
an endwall which is non-rotating). This boundary condition requires the specification of 
additional data, as shown in the boundary data format descriptor above. The first addi- 
tional line following the SSVI specification is assumed to be a label and may contain any 
information; however, for consistency it is recommended that the labels RPMWALL and 
TWALL be used. The next line contains the values imposed for t he variables RPMWALL 
and TWALL. The value of the RPMWALL variable is the desired solid wall dimensional 
rotational speed in revolutions per minute. This value is sign dependent and follows the ori- 
entation for rotation as described in Figure 3.10. The variable TWALL determines which 
tvpe of temperature condition is applied to the surface. If TWALL=0.0. an adiabatic wall 
is assumed. For TWALL>().(). a constant temperature surface with a nondimensional wall 
temperature of TWALL defined as: 


/ 7-’ \ __ J wall 

l ' wall )non — dimf naionul — . • 

Otj 

is imposed . (Here 7 , f is the reference temperature imposed by the input file variable 
TREF.) A value of TWALLcO.O is not permitted. Naturally, poor convergence or solu- 
tion divergence can occur if RPMWALL or TWALL suggest boundary values which are 
significantly different from the remainder of the flowfield. In such cases where this occurs, 
il is recommended that the solution be started with more conservative boundary values, 
and then restarted using the final boundary values. 

Restrictions/Limitatioiis 


The SSVI boundary specification is restricted to :M) mesh surfaces (2-1) mesh surfaces 
should use the SS2DVI boundary specification). The boundary rotational speed imposed 
by the SSVI boundary condition can only be nonzero when using the cylindrical coordinate 
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solution algorithm in the ADPAC07 code. When using the Cartesian coordinate solution 
algorithm FCART and/or FCARB= 1.0. the boundary rotational speed must be zero 
(RPMWALL= 0.0 when FCART and/or FCARB^ 1.0). Refer to the Chapter on input, 
file parameters for a description of TREF. RPM, FCARB. and FCART. 


Common Errors 


• Incorrect sign for value of boundary rotational speed RPMWALL. 

• Attempt to utilize a nonzero boundary rotational speed with the ('artesian coordinate 
solution algorithm. 

• Application of SSVI to a 2-1) mesh system. 
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SYSTEM 


AD PA CO 7 UNIX System Call Specification 


Time-Marching Loop 




Application 


The SYSTEM specification is not a boundary condition as such, but directs t lie AD- 
PAC07 code to perform a UNIX system call at every application of the boundary condition 
loop. In t he application illustrated above, every time the ADPAC07 code encounters the 
boundary condition specification SYSTEM the code is directed to perform a UNIX system 
call of the command updntfbc . which is presumably a user-specified code used to update 
certain boundary variables (see sample format below). This new data could then be im- 
ported using the BDATIN boundary specification. The SYSTEM function can quickly 
lead to trouble due to the number of times it is called within the time-marching strategy, 
and the user should thoroughly review the documentation below before attempting to use 
this facility. 


Boundary Data File Format 


The boundary data file specifications for the mesh interface indicated in the illustrative 
graphic for the SYSTEM boundary condition are given below: 


SYSTEM 1 1 J J P P I K 1 1 11 21 1 11 11 21 1 11 
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INTERVAL 

1 

COMMAND 

/usr/local/bin/updatebc 


Note that a complete SYSTEM specification requires the specification of additional data 
beyond the standard boundary specification line. 


Description 


The SYSTEM statement is provided to permit the specification of a UNIX system call 
from within the ADPAC07 code. Once the SYSTEM specification is directed into the 
ADPAC'07 code, at a specified interval of iterations, during every execution of the bound- 
ary condition loop, when the SYSTEM specification is encountered, the code executes 
the command provided by the SYSTEM specification and pending successful completion, 
continues execution. The SYSTEM specification is based on the FORTRAN intrinsic sys- 
tem function which must be available in the compiling system. It should be noted that 
the command dictated by the SYSTEM specification could be performed every time the 
boundary condition loop is encountered. This suggests that the system call could be made 
a minimum of four times for each iteration of the time-marching scheme (for the four stage 
scheme). This number can grow rapidly if more complicated iteration strategies are used 
such as multigrid, subiterations, etc., and the user should be warned that such redundant 
system calls can wreak havoc on an otherwise friendly solution. A SYSTEM specification, 
in conjunction with the BDATIN/BDATOU boundary data specifiers can be effectively 
combined to provide a run time interface between the ADPAC'07 code and an external flow 
solver. 

A SYSTEM specification requires four additional lines in addition to the normal bound- 
ary data file descriptor, as shown above. The first additional line simply contains the label 
for the iteration interval INTERVAL, followed by the actual value of INTERVAL. The 
SYSTEM routine will only be invoked every INTERVAL time-marching iterations. The 
next line contains the label for the system call command (COMMAND) variable. The fol- 
lowing line contains the actual UNIX command to be issued at every SYSTEM encounter 
in the boundary condition loop. 

Restrictions/Liinitations 


Data provided in the SYSTEM specification should represent a valid UNIX system com- 
mand. The FORTRAN intrinsic function system must be available on the compiling system. 
The SYSTEM function is not available on the Cray or n(TBE computers. 


Common Errors 


• Invalid UNIX system command provided in SYSTEM boundary specification. 
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• Failure to provide the additional data INTERVAL and COMMAND for SYSTEM 
specification. 

• FORTRAN intrinsic function system unavailable at compile time. 

• User unaware that SYSTEM action occurs four or more times per iteration. 

• Attempt to use the SYSTEM specification on a (’ray. n(TBF. or other incompatible 
computer system. 
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TRAF 


TRAF2D/3D Type Noil- Contiguous Mesh Block Interface Patch- 
ing Scheme 




Non-Contiguous Mesh Block Interface Along 
Wake Cut Line Requires a TRAF Specification 
(illustrated in Boundary Data File Format 
statements below) 


Application 


The TRAF specification was developed specifically to treat C-type mesh systems for 
airfoil cascades with a noncontiguous wake cut line such as those developed using t he 
TRA F2D/TRA FSD [20] flow solver. The example graphic above illustrates a t wo-dimensional 
mesh system used to predict the flow through a turbine vane passage. This mesh was gen- 
erated using the JERRYC/TOMC mesh generation package which was developed for the 
TRA F2D/TRA F-iD flow solver. The C-type mesh utilizes a noncontiguous wake cut line as 
shown in the trailing edge detail. The TRAF specification is applied along either side of 
the wake cut line to permit communication of flow variables across the noncontiguous mesh 
interface. 


Boundary Data File Format 
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The boundary data file specifications for the mesh interface indicated in the illustrative 
graphic for the TRAF boundary condition are given below: 

TRAF 1 1 J J P P L L 1 1 1 33 1 2 177 193 1 2 

TRAF 1 1 J J P P L L 1 1 177 193 1 2 1 33 1 2 

Note that a complete TRAF specification generally requires two TRAF statement lines in 

the boundary data file. In the example above, the first specification provides the interblock 
communication for one side of the ( -grid wake cut. while the second specification provides 
the communication for the other side of the ('-grid wake cut. It is a common error to 
underspecify a TRAF boundary by only providing a single line per interface. 


Description 


The TRAF boundary statement provides a means for block to block communication for 
cases involving neighboring mesh boundaries which share a common surface, but are non 
contiguous in one grid index. The standard example of this type of mesh is a ('-type 
mesh about an airfoil where the points along the ('-grid wake cut line are noncontiguous. 
This type of mesh system has been utilized extensively in the THAI 2D/TRAFJD [20] 
flow solver system, and the TRAF boundary specification has been provided to permit 
/I I)PA( ()7 execution on these meshes. T he implied rest riction of t he TRAF boundary 
specification is that the mesh is only misaligned in one coordinate direction, specifically the 
/ coordinate. It is also assumed that the endpoints of the TRAF boundary specification 
are contiguous. As such, the TRAF boundary specification is fairly restrictive, and should 
not be used as a general purpose misaligned mesh routine. (The BCINT1, BCINTM 
and PINT boundary specifications are available for connect ing generalized misaligned mesh 
boundaries.) An example of an appropriate application of the TRAF specification is given 
in the illust rative graphic. The TRAF boundary specification is valid for either 2-1) or 3-1) 
mesh blocks. For 2-1) mesh blocks, t he TRAF specification must be applied to a j=constant 
boundary. For 3-1) mesh blocks, the TRAF specification must be applied to a ^constant 
boundary. The TRAF boundary condition requires no additional data beyond the initial 
specification line, but does require some extra care when used. The primary precaution 
is that the TRAF procedure is based entirely on a simplified cubic spline interpolation 
scheme, and hence, does nol maintain either global or local conservation of flow variables 
across the mesh interface. 


Restrict ions/Limitations 


The TRAF boundary specification is restricted to mesh interfaces which lie on a common 
surface (no significant overlap). The TRAF procedure permits only that the i coordinates 
between adjacent mesh surfaces are misaligned. The TRAF procedure is only valid if the 
misaligned i coordinates either increase or decrease in the x direction monotonically. The 
endpoints of the TRAF specification surface must be contiguous. The TRAF specification 
may only be applied to ^constant, surfaces for 2-1) mesh blocks, and J*=constant surfaces 
for 3-1) mesh blocks. 
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Common Errors 


• Failure to provide 2 TRAF statements for each interface. 

• Incorrectly specified or misaligned extents of boundary regions (values of M1LIM1, 
M1LIM2, N1LIM1, N1LIM2, M2LIM1, M2LIM2, N2LIM1, N2LIM2 do not 
correctly define the interface extents on blocks LBLOCKl and LBLOCK2). 

• Attempt to use TRAF for a boundary which has 2 misaligned coordinates. 

• Attempt to use TRAF for boundaries which are not monotonic in the x direction. 

• Application of TRAF to mesh interfaces which do not have contiguous end points. 

• Application of TRAF to an /^constant or A — constant mesh surface in a 2-1) block. 

• Application of TRAF to an /^constant or ^constant mesh surface in a :M) block. 



ADPAC'07 Mesh File Description 


201 


3.8 Mesh File Description 

The ADPAC07 rase. mesh file is a data file containing the .r, t /y.~ grid coordinates of the 
multiple mesh blocks which are read in to define the physical grid points used in the time- 
marching solution (see Section 3.5 for a description of the ras( name and the mesh file 
naming convention). The mesh coordinates are specified in a Cartesian frame of reference, 
as shown in Figure 3.11. although the A DPj \C07 program may ultimately convert these 
coordinates to a cylindrical coordinate system during execution. Regardless of whether the 
user intends to utilize the ADPAC07 code in a Cartesian or cylindrical solution mode, the 
mesh file coordinates are always defined by the ('artesian coordinates .r. y. and c. The 
mesh coordinates are stored in what is known as PLOT AD multiple grid format, and are 
formatted using the Scientific Database Library (SDBL1B). (The SDBLIB system allows 
machine-independent binary file storage.) The case. mesh file must be available for every 
ADPAC07 run. At the beginning of program execution, the A DPA('07 program attempts 
to open the mesh file and read in the mesh size to make sure that enough memory has been 
allocated for the given problem. If the mesh file is not found, or if the mesh is too large, 
the appropriate error message is issued, and the program will terminate. 

M esh coordinates are assumed to be nondimensional numbers. The ADPAC07 code 
employs a dimensional scaling factor (see input file variable DIAM) to convert the nondi- 
mensional mesh coordinates into dimensional coordinates with units of feet. If the mesh 
is generated with units of feet, then the dimensionalizing factor is simply 1 . 0 . Proper 
nondimensionalization and specification of the dimensionalizing factor DIAM is required 
in order to accurately achieve the desired flow Reynolds number and rotational speed (see 
the discussion of input variable ADVR is Section 3.6). It is also required that the ordering 
of the mesh points form a "left-handed'* mesh. This implies that at every point in the mesh, 
the vectors representing the positive /, 7 , and k coordinate directions form a left-handed 
coordinate system (see Figure 3.12). Consider the case of a sheared Il-grid discretizing a 
single blade passage of a compressor (this type of mesh is used extensively in t he Standard 
Configurations described in Chapter 5). If we assume that looking downstream through 
the blade passage is essentially the positive i direction, and that the radial direction from 
hub to tip is essentially the positive j direction, a. left-handed mesh would require that the 
positive k direction be from right to left (counterclockwise) in this orientation. 

In order to understand the PL OTSD multi pie- grid mesh file format, and the utilization 
of the SDBLIB routines, a comparison of the FORTRAN coding for each method is given 
below for comparison. 

The FORTRAN coding to read a PLOT AD unformatted multiple- block mesh file might 
be given as: 


PLOT3D Mesh File Format FORTRAN Coding Example 


OPEN (UNIT=IGRID , FILE=FNAME ,F0RM= ’ UNFORMATTED > , STATUS= ’ OLD » ) 
READ (IGRID) MG 

READ(IGRID) (IL(L), JL(L) , KL(L) ,L=1 ,MG) 

DO 10 L = 1, MG 

READ (IGRID) ( ( (X(I , J ,K ,L) , 1=1 , IL(L) ) , J=1 , JL(L) ) ,K=1 ,KL(L) ) , 
(((Y(I,J,K,L),I=1,IL(L)) ,J=1,JL(L)),K=1,KL(L)) , 
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ADPAC Coordinate System Reference 


Cartesian Coordinate 
Reference 


Z A 



Figure 3.11: ADPAC07 mesh coordinate reference description 
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ADPAC Left-Handed Coordinate Description 

All ADPAC Mesh Blocks Must Be 
Based on a Left-Handed Indexing System 


Left-Handed Mesh System 



K 


Figure ADPAC'Ql left-handed coordinale system description 
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(((Z(I,J,K,L) ,I=1,IL(L)) ,J=1,JL(L)) ,K=1,KL(L)) 

10 CONTINUE 


Each of the terms used in the FORTRAN code given above are defined below: 

ICR ID FORTRAN unit number for read statement 

FNAME File name for mesh file 

MG number of grid blocks 

IL(L) maximum i grid index for block L 

JL(L) maximum j grid index for block L 

KL(L) maximum k grid index for block L 

X(I.J.K.L) Ca rtesian coordinate value of x for point (1..J.K) in block L 

Y(I.J.K.L) Cartesian coordinate value of y for point (l.J.K) in block L 

Z(I.J.K.L) Cartesian coordinate value of z for point (l.J.K) in block L 

An example of the corresponding FORTRAN coding to read an ADPAC07 binary mesh 
file using the Scientific Database Library (SI)BLIB) routines is given below: 


PLOT3D Mesh File Format FORTRAN Coding Example Using SDBLIB 


CALL QDOPENC I GRID , FNAME, JE ) 

CALL QDGETI ( I GRID , MG , JE ) 

DO L = 1, MG 

CALL QDGETI ( I GRID , IL(L), JE ) 

CALL QDGETI ( I GRID , JL(L), JE ) 

CALL QDGETI ( I GRID , KL(L) , JE ) 

ENDDO 
IPOINT = 1 
DO 10 L = 1, MG 

I LENGTH = IL(L) * JL(L) * KL(L) 

CALL QDGEEA( IGRID, X(IPOINT), ILENGTH, JE ) 

CALL QDGEEAC IGRID, Y(IPOINT) , ILENGTH, JE ) 

CALL QDGEEA( IGRID, Z(IPOINT), ILENGTH, JE ) 

IPOINT = IPOINT + ILENGTH 
10 CONTINUE 

CALL QDCL0S( IGRID, JE ) 


A listing of the additional terms used in the coding above is given below: 

QDOPEN SDBLIB routine to open a file for input or output 
QDGETI SDBLIB routine to get an integer 

QDGEIA SDBLIB routine to get an integer array of length ILENGTH 
QDGETE SDBLIB routine to get a real number 
QDGEEA SDBLIB routine to get a real array of length ILENGTH 
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QDCLOS SDBLIB routine to close a file 

IGRID FORTR AN logical unit number for grid input 

.JE An error trigger; 0 for no error. ^ 0 if an error occurs 

IB Integer array containing the IL. .IF, and KL grid block sizes 

ILENGTH Integer length of an array of data 

IPOINT Integer pointer for block L to locate the initial memory lo- 
cation for a block of data 

The x.y.z coordinates are read in as a single-dimensioned array in the SDBLIB for- 
mat. and the A DBA C07 program includes a conversion routine (source file canvas. f) which 
converts the single dimension array data to a three-dimensional data array. 

The mesh file may be utilized directly with the BLOTSD program when the default 
real number size of the compiled BLOTS!) code is defined as 52 bits (as it is on many 
workstations). The corresponding PLO TSI) read command for an A DPA('()7 mesh file are: 


PLQT3D PR0MPT> read/mg/bin/x=case .mesh 


Obviously, the user should substitute his/her own case name in the BLOTS I) input line. 

Unformatted mesh files may be converted to ADBAC07 format using the MAKEAD- 
ORID program described in Chapter 7. It should be emphasized that the phantom cells 
used in the application of boundary conditions are automatically defined within the A D- 
PA('07 code. and the user need not be concerned about generating fictitious points within 
the mesh to accommodate the boundary condition application procedure (mesh points need 
only be generated for the actual flow domain). 


3.9 Body Force File Description 

The ADPA('()7 body force file is a data file containing the blade blockage, body force, and 
energy source terms used in a 2- D axisymmetric representation of an embedded blade row 
(see 2- D/5- 1) Solution Concepts, Section 2.5). Individual body force files contain the cell- 
centered blade blockage, body forces, and energy source terms for a specific mesh block. As 
a result, the file naming procedure for the body force file is somewhat different than the 
mesh, plot and restart files, where a single file contains all the data for a multiple-block 
solution (a complete description of the ADBAC07 file naming procedure is given in Section 
5.5). 

The terms in the body force file are stored in binary format, based on the Scientific 
Database Library routines. (The SDBLIB system permits machine-independent binary 
file storage.) The blockage, body forces, and energy sources are stored as nondimensional 
numbers using the nondimensionalization strategy described in the Final Report [21]. 

In order to understand the body force file format, and the utilization of the SDBLIB 
routines, a representative FORTRAN coding example to read in a body force file is given 
below for comparison. 
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CALL QD0PEN( IBODY , FNAME, JE ) 

CALL QDGETIC IBODY, NG , I LENGTH , JE ) 

CALL QDGETIC IBODY, IMX, ILENGTH , JE ) 

CALL QDGETI ( IBODY, JMX, ILENGTH, JE ) 

CALL QDGETIC IBODY, KMX, ILENGTH, JE ) 

ILENGTH = IMX * JMX * KMX 

CALL QDGETEC IBODY, DUMMY, JE ) 

CALL QDGETEC IBODY, DUMMY, JE ) 

CALL qDGETEC IBODY, DUMMY, JE ) 

CALL qDGETEC IBODY, DUMMY, JE ) 

CALL QDGEEAC IBODY, BFR CIPOINT(L)), ILENGTH, JE ) 

CALL QDGEEAC IBODY, BFRU ClPOINTCD), ILENGTH, JE ) 

CALL QDGEEAC IBODY, BFRV CIPOINT(L)), ILENGTH, JE ) 

CALL QDGEEAC IBODY, BFRW CIPOINTCL)), ILENGTH, JE ) 

CALL QDGEEAC IBODY, BFRE CIPOINTCL)), ILENGTH, JE ) 

CALL QDGEEAC IBODY, BL CIPOINT(L)), ILENGTH, JE ) 

CALL qDGEEAC IBODY, BP CIPOINTCL)), ILENGTH, JE ) 

CALL qDCLOSC IBODY, JE ) 


A listing of the FORTRAN variables and their meanings is given below: 

QDOPFN SDBLIB routine to open a file for input or output 
QDGETI SDBLIB routine to get an integer 
QDGETE SDBLIB routine to get a real number 
QDGEEA SDBLIB routine to get a real array of length ILENGTH 
QDC'LOS SDBLIB routine to close a file 
IBODY FORTRAN logical unit number for body force fde input 
JE An error trigger: 0 for no error, / 0 if an error occurs 
NG Number of blocks in body force file (must be 1) 

IMX Mesh size+1 in the i coordinate direction 
JMX Mesh size+1 in the j coordinate direction 
KMX Mesh size+1 in the k coordinate direction 
ILENGTH Integer length of an array of data 

IPOINT(L) Integer pointer for block L to locate the initial memory lo- 
cation for a block of data 

BFR Body force for density (continuity equation) 

BFRU Body force for axial momentum 
BFRV Body force for radial momentum 
BFRW Body force for circumferent ial momentum 
BFRE Body force for internal energy 
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BL Blockage term 

BP Pressure correction term (currently unused) 

The body force data are read and written as a single-dimensioned array in the SDHLIB 
format, and the A DPAC07 program includes a conversion routine (source file convas.f) 
which converts the one-dimensional array data, to three dimension array data. 


3.10 Standard Output File Description 

The ADPAC'Ol standard output file rase . output provides information regarding the status 
of a particular calculation during code execution. The status information includes startup, 
code response to input files (mesh, restart, standard input, and boundary data), convergence 
history, error messages, and output file generation (plot files, restart files, body force files). 
The information given in the standard output file is essentially self explanatory, so no further 
description is given here. A sample output file is included in the standard distribution of 
the ADPAC07 code for the test case described in Appendix A. Additional details may be 
found in this Appendix. 


3.11 Plot File Description 

The ADPAC07 ra*c.p3dabs and case. p3drel plot files contain predicted absolute and rel- 
ative frame of reference flow data values, respectively, for each of the mesh points in a 
multiple-block mesh ADPAC'Ol solution. The grid-centered aerodynamic data is obtained 
by algebraically averaging the cell-centered data generated by the finite- volume solver during 
the time-marching process. As a result of the averaging procedure, this data can occasion- 
ally appear inconsistent at t he corners of a mesh block, and should therefore only be used 
for graphical viewing, and not for post processing to obtain performance data, mass flow 
rates, pressure rise. etc. The flow plot data are specified in a Cartesian coordinate sys- 
tem (velocities are r r ,r v . r~) to be consistent with the representation of the mesh file (see 
Section :j.K). The plot files are written in what is known as PLOTS!) multiple grid binary 
format. The plot data are formatted using the Scientific Database Library (SDBL1B). (The 
SDBL1B system permits machine-independent binary file storage.) The flow data are listed 
as nondimensional numbers using the nondimensionalization strategy described in the Final 
Report [21]. 

In order to understand the PLOTSD multiple-grid flow fde format, and the utilization 
of the SDHLIB routines, a comparison of the FORTRAN coding for each method is given 
below for comparison. 

The equivalent. FORTRAN coding for an unformatted PLOTSD flow file could be given 
as: 


PLOT3D Flow File Format FORTRAN Coding Example 
WRITEC ) MG 

WRITEC ) ( I L (L ) , JL(L), KL(L) ,L=1 ,MG) 

DO 20 L = 1, MG 
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WRITEC ) EM(L) , REY(L), ALF(L) , TIME(L) 

WRITEC ) ( ( CR (I , J ,K ,L) ,I=1,IL(L)),J=1, JL(L) ) ,K=1 ,KL(L) ) , 
(((RU(I,J,K,L) , 1=1 , IL(L) ) , J=1 , JL(L) ) ,K=1,KL(L)), 
(((RV(I,J,K,L) , 1=1 , IL(L) ) , J=1 , JL(L) ) ,K=1 ,KL (L) ) , 
( ( (RW(I , J ,K,L) , 1=1 , IL(L) ) , J=1 , JL(L) ) ,K=1 ,KL(L) ) , 
(((RE(I,J,K,L) , 1=1 , IL(L) ) , J=1 , JL(L) ) ,K=1,KL(L)) 

20 CONTINUE 


Kadi of the terms used in the FORTRAN code given above are defined below: 
MG number of grid blocks 
IL(L) maximum i grid index for block L 
JL(L) maximum j grid index for block L 
KL(L) maximum k grid index for block L 

X(LJ.K.L) Cartesian coordinate value of x for point (LJ.K) in block L 

Y(IJ.K.L) Cartesian coordinate value of y for point (LJ.K) in block L 

Z(U,K,L) ('artesian coordinate value of z for point (LJ.K) in block L 

EM(L) FLOTSD Reference Mach number for block L 
REY(L) PLOTSD Reference Reynolds number for block L 
ALF(L) PLOTSD Reference angle for block L 
TIME(L) PLOTSD Reference time for block L 
R (IJ.K.L) p at point (LJ.K) in block L 
RU(LJ.K.L) pu x at point (IJ,I\) in block L 
RV(KTKX) pu y at point (LJ.K) in block L 
RW(K.FKX) pu z at point (I,J,I\) in block L 
RE(KJ.K.L) pe at point (LJ.K) in block L 


PLOT3D Flow File Format FORTRAN Coding Example Using SDBLIB 


CALL QDGPEN( IFLOW, FNAME , JE ) 
CALL QDPUTIC IFLOW, MG , JE ) 

DO L = 1, MG 

CALL QDPUTI ( IFLOW, IL(L), JE ) 

CALL QDPUTI ( IFLOW, JL(L) , JE ) 

CALL QDPUTIC IFLOW, KL(L) , JE ) 

ENDDO 

IPQINT = 1 

DO 20 L = 1, MG 

ILENGTH = IL(L) * JL(L) * KL(L) 
CALL QDPUTEC IFLOW, EM(L) , JE ) 

CALL QDPUTEC IFLOW, REY(L) , JE ) 

CALL QDPUTEC IFLOW, ALFCL) , JE ) 
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CALL QDPUTEC IFLOW, TIME(L) , JE ) 

CALL QDPUEA( IFLOW, R (IPOINT), ILENGTH , JE ) 

CALL QDPUEA( IFLOW, RU(IPOINT) , ILENGTH, JE ) 

CALL QDPUEA( IFLOW, RV(IPOINT) , ILENGTH, JE ) 

CALL QDPUEA( IFLOW, RW(IPOINT) , ILENGTH, JE ) 

CALL QDPUEA( IFLOW, RE(IPOINT) , ILENGTH, JE ) 

IPOINT = IPOINT + ILENGTH 
20 CONTINUE 

CALL QDCLOS( IFLOW, JE ) 


A listing of the additional terms used in the coding above is given below: 

Q DO PEN SDBLIB routine to open a file for input or output 

QDPUTI SDBLIB routine to write an integer 

QDPUTE SDBLIB routine to write a real number 

QDPUEA SDBLIB routine to write a real array of length ILENCTH 

QDCLOS SDBLIB routine to close a file 

IFLOW FORTRAN logical unit number for flow input 

JE An error trigger: 0 for no error, ^ 0 if an error occurs 

IB Integer array containing the IL. JL. and KL grid block sizes 

ILENGTH Integer length of an array of data 

IPOINT Integer pointer for block L to locate the initial memory lo- 
cation for a block of data 


The plot files may be utilized directly with the PLOTSD program when the default 
real number size of the compiled PLOTSl) code is defined as 32 bits (as it is on many 
workstations). The corresponding PLOTS!) read commands for an ADPACOJ mesh and 
flow file are: 


PL0T3D PR0MPT> read/mg/bin/x=case .mesh/q=case .p3dabs 


Obviously, the user should substitute his/her own case name in the PLOTSD input line. 

For solutions employing the two-equat ion k-lZ turbulence model, an additional PLOTSD- 
compatible file is written for plotting the turbulence parameter data. The case. p3d2eq file 
is identical in format to that given above except that the variables RV and RY are replaced 
with the turbulence parameters pk and p'/v, respectively. The user must be cautioned to 
avoid using this file in conjunction with PLOTSD functions which require specification of 
all the velocity components (pressure and temperature are two examples). 


3.12 Restart File Description 

The ADPACO 7 restart file is a data file containing the cell-centered flow variables generated 
during an A I) PA CO 7 solution. This file is intended to permit continued execution of the 
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code from the point, at which a previous calculation was terminated. This feature permits 
breaking large jobs into smaller computational pieces. This process of job restarting is 
considered a good practice to avoid loss of data due to computer malfunctions and job 
quota limitations. At the end of a given job, whether the calculat ion is a restart run or not . 
the ADFAC'07 program will attempt to write out the current cell centered data to the file 
case, restart, new (see Section 3.2 for a description of the file naming convention). The restart 
file may then be used to continue the calculation at this same point bv simply renaming 
the file case .restart. new to case. restart. old. setting the input trigger appropriately (see the 
description of FREST in Section 3.6), and rerunning the code. The restart data are writ ten 
in either the cylindrical or Cartesian coordinate system depending on the variable format 
used during execution of t he ADPAC07 code for each particular mesh block. Velocities 
are specified as either v x .Vy. v~ (Cartesian) or v x , v r ,vg (cylindrical), and all flow variables 
utilize the nondimensionalization strategy described in Section 1.2 of the companion Final 
Report [4]. 

In order to demonstrate the format of the restart file, a sample of the FORTRAN coding 
utilizing the SDBLIB library required to read a restart file is given below. 

ADBAC07 Restart Flow File Format FORTRAN Coding Example 


CALL QDOPENC IREST, FNAME , JE ) 

CALL QDGETIC IREST, MG , JE ) 

DO 1 N = 1, MG 

CALL QDGETIC IREST, IMX(N) , JE ) 

CALL QDGETIC IREST, JMXCN) , JE ) 

CALL QDGETIC IREST, KMXCN) , JE ) 

1 CONTINUE 

DO 10 N = 1, MG 

LENGTH = IMX(N) * JMX(N) * KMXCN) 

CALL QDGEEAC IREST, R (IJK(N)), LENGTH, JE ) 

CALL QDGEEAC IREST, RUCIJKCN)), LENGTH, JE ) 

CALL QDGEEAC IREST, RVCIJKCN)), LENGTH, JE ) 

CALL QDGEEAC IREST, RWClJKCN)), LENGTH, JE ) 

CALL QDGEEAC IREST, RE(IJK(N)), LENGTH, JE ) 

CALL QDGEEAC IREST, P CIJK(N)), LENGTH, JE ) 

10 CONTINUE 

NLENGTH = MG 

CALL QDGEIAC IREST, NCYC , NLENGTH , JE ) 

CALL QDGEIAC IREST, DTHETA , NLENGTH , JE ) 

CALL QDGEIAC IREST, OMEGAL , NLENGTH , JE ) 

optional additional data for implicit calcaidations 


CALL QDGETI ( IREST, IDATA, JE ) 

DO 20 N = 1, MG 

LENGTH = IMXCN) * JMXCN) * KMX(N) 

CALL QDGEEAC IREST, RM1 ClJKCN)), LENGTH, JE ) 
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CALL QDGEEAC IREST, RUM1 (I JK(N) ) , LENGTH, JE ) 

CALL QDGEEAC IREST, RVM1 (I JK(N) ) , LENGTH, JE ) 

CALL QDGEEAC IREST, RWM1 (I JK(N) ) , LENGTH, JE ) 

CALL QDGEEAC IREST, REM1 Cl JK (N) ) , LENGTH, JE ) 

CALL QDGEEAC IREST, RM2 (IJK(N)), LENGTH, JE ) 

CALL QDGEEAC IREST, RUM2(I JK(N) ) , LENGTH, JE ) 

CALL QDGEEAC IREST, RVM2(I JK(N) ) , LENGTH, JE ) 

CALL QDGEEAC IREST, RWM2(I JK(N) ) , LENGTH, JE ) 

CALL QDGEEAC IREST, REM2(I JK(N) ) , LENGTH, JE ) 

20 CONTINUE 

CALL QDCLOSC IREST, JE ) 

Each of t he terms used in the FORTRAN code given above are defined below: 

MG number of grid blocks 
IMX(L) maximum i grid index for block L 
JMX(L) maximum j grid index for block L 
KMX(L) maximum k grid index for block L 
R (IJK(L)) p at point IJK(L) in block L 
RU(1JK(L)) pu r at point I.JK(L) in block L 
RV(IJI\(L)) ptiy at point IJK(L) in l)lock L 
R\Y(IJK(L)) P*h at point IJK(L) in block L 
RF(IJI\(L)) p< at point IJK(L) in l>lock L 
P (UK(L)) pressure at point IJK(L) in block L 
QDOPEN SDBLIB routine to open a file for input or output 
QDGETI SDBLIB routine to get an integer 

QDGEIA SDBLIB routine to get an integer array of length ILENGTH 

QDGEEA SDBLIB routine to get a real array of length ILENGTH 

QIX’LOS SDBLIB routine to close a file 

IREST FORTRAN logical unit number for restart input 

JE An error trigger; 0 for no error, ^ 0 if an error occurs 

IB Integer array containing the IMAX, JMAX, and I\M AX grid block 
sizes 

ILENGTH Integer length of an array of data 

IJK(L) Integer pointer for block L to locate the initial memory location 
for a block of data 

NGYC Iteration number when restart file was written 
DTHETA Block rotation increment (A#) 

OMEGAL Block rotational speed (nondimensional) 
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IDATA 

RM1 (IJK(L)) 
RUM1(IJK(L)) 
RVM1(IJK(L)) 
RWM1(IJK(L)) 
REM1(IJK(L)) 
RM2 (I.TK(L)) 
RUM2(IJK(L)) 
RVM2(IJK(L)) 
RWM2( IJK(L)) 
REM2(IJK(L)) 


Implicit restart data trigger (0-no implicit data, 1-restart data 
follows ) 

p at point I,TK(L) in block L (N-l time level) 
pu r at point I.JK(L) in block L (N-l time level) 

pu y at point IJK(L) in block L (N-l time level) 

pu~ at point I.JK(L) in block L (N-l time level) 

pe at point 1JI\(L) in block L (N-l time level) 
p at point 1JK(L) in block L (N-2 time level) 
pUj- at point IJK(L) in block L (N-2 time level) 

pity at point IJK(L) in block L (N-2 time level) 

pu~ at point 1JK(L) in block L (N-2 time level) 

pe at point IJK(L) in block L (N-2 time level) 


The rest art data are read as a single-dimensioned array in the SDBLIB format, and the 
ADPAC'07 program includes a conversion routine (source file conms.f) which converts the 
one-dimensional array data to three-dimensional array data. 


For solution employing the iterative implicit time-marching algorithm, several time levels 
of data must be stored in the restart, file to properly restart the solution. The additional 
time levels of data are stored immediately following the current time level data and a simple 
trigger variable (IDATA. above) which informs the code of the existanee of the additional 
time level data. If no additional data are present in the restart file, and an implicit solution 
is being restarted, the code initializes the additional time level data arrays with the best 
available values. 


3.13 Convergence File Description 

The ADPAC07 convergence history file case converge (see Section 3.5 for a description of 
the ADPAC07 file naming convention) is an ASCII data file which contains the residual 
convergence history of the time-marching solution. The residual history is useful for deter- 
mining whether the numerical solution has converged sufficiently to permit interrogation of 
the numerical results, or whether additional restarted calculations are required to obtain 
an accurate solution. Typically, a solution is deemed converged when the residuals have 
been reduced by three orders of magnit ude or more. The data in the case .converge file are 
organized in the following format: 


CYCLE 

NUMBER 

MAXIMUM 

ERROR 

RMS 

ERROR 

MASS 

INFLOW 

MASS 

OUTFLOW 

PRESSURE 

RATIO 

ADIABATIC 

EFFICIENCY 

NUMBER 
SS PTS 

NUMBER 

SEPPTS 

301 

-2.17895 

-5.52081 

3.46778 

3.46781 

1.58615 

0.88737 

308 

0 

302 

-2.42051 

-5.57462 

3.46777 

3.46656 

1 . 58762 

0.89150 

315 

0 

303 

-2.65891 

-5.64842 

3.46774 

3.46646 

1 . 58949 

0 . 89685 

317 

0 

304 

-2.78033 

-5.71740 

3.46765 

3.46781 

1.59123 

0.90145 

320 

0 



A D PAC'D? linage File Description 


213 


The residual R at any cell in the finite volume solution is calculated as the sum of the 
changes in the 5 conservation variables p, pu* pi\ pu\ and pc . The maximum residual is then 
defined as the maximum of all the residuals over all the cells of all mesh blocks. The root- 
mean square residual is the square root of the sum of the squares of all the cells for all mesh 
blocks. The case .converge file residual data are reported as the base 10 logarithm of the 
actual residuals in order to quickly evaluate the convergence of tin* solution (if t lie reported 
loglO maximum residual starts at -2.5 and ends up at -5.5. the solution has converged 
three orders of magnitude). Several additional data are also output, to the convergence 
file based on flow parameters occurring across inflow and outflow boundaries. Since many 
flow cases involve a single inlet and a single exit, a useful measure of convergence is the 
difference between the inlet and exit mass flow rate, and how much the mass flow rate varies 
from iteration to iteration. For 2-1) (’artesian flow calculations a unit depth (1.0 in mesh 
coordinates) is assumed for the third coordinate direction to determine the mass flow rate. 
For 2-1) cylindrical flow calculations, t he geometry is assumed to be axisymmetric (in the ./■- 
r plane) and a multiple of 27T is used in the mass flow integration (the mass flow is computed 
as if the full circumference of the axisymmetric geometry were employed). Data are provided 
in the convergence file for the sum of all mass crossing any inflow boundary (INLETG, 
INLETG, INLETT, INLETM, INLETR and all mass crossing any exit boundary 
EXITG, EXITX, EXITT, EXITP. The pressure ratio, or ratio of mass-averaged total 
pressures from all inlet and exit boundaries is also reported in the convergence file, as 
well as the adiabatic efficiency computed based on mass-averaged total temperature and 
total pressure of the inflow and outflow boundaries, respectively. Finally, the number of 
computational cells with supersonic flow and the number of computational cells indicating 
separated flow (negative r r ) are also reported in the convergence history file. 

The rase. converge file is formatted in columns to permit convenient plotting using any 
of a number of x-y plotting programs (the FVLLPLOT program described in Reference [fi] 
is one example). 

In the event that the k — Tv turbulence model is enabled (F2EQ = = 1 .0). the convergence 
characteristics of the turbulence transport equations is output immediately following the 
convergence characteristics of the continuity, momentum, and energy equations at every 
iteration. This “alternating line** output somewhat complicates the contents of the conver- 
gence file, but has been found useful to simultaneously monitor both the momentum and 
turbulence transport equation convergence characteristics. 


3.14 Image File Description 

The A DP : 1 CD? graphics display system (see Chapter 9) has the capability of saving a raster 
image of the local graphics screen to a file at specific iteration intervals using the Silicon 
Graphics image file format. This feature is included as a simple means of constructing flow- 
field animations. The input variables dealing with this facility FGRAFIX, FGRAFINT, 
FIMGSAV, FIMGINT are d escribed in Section 3.0, and the image file naming conven- 
tion is described in Section 3.5. In short, image files can be saved when the graphics display 
system is running on a single Silicon Graphics workstation or across a network between 
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two Silicon Graphics workstations supporting the IRIX Operating System Version 4.0.1 or 
above, and also supporting the IRIX scr.sa.ve command. Image files can be viewed after 
they have been saved bv issuing the command 


ipaste case.img.# 

Other Silicon Graphics IRIX Operating System-specific commands such as imgview, movie 
and others may also be suitable for viewing image files. Additional information on the IRIS 
image format and the image manipulation commands are available in the Silicon Graphics 
system documentation . 

3.15 Running ADPAC07 With 2-Equation Turbulence Model 

3.16 2-Equation Turbulence Model Solution Sequence 


In order to run ADPAC07 with the two-equation k - R turbulence model enabled, the follow- 
ing steps must be taken. First, the input file trigger F2EQ must be enabled (value=1.0). 
This activates the additional partial differential equation solution scheme for the k - R 
model. Note that this completely disables the standard algebraic (Baldwin-Lomax) tur- 
bulence model and the wall function formulation. The lack of w'all functions implies that 
the mesh must be sufficiently refined to adequately resolve the inner (laminar sublayer) 
of the turbulent boundary layer flow. There is, at present , no built in mechanism in the 
ADPAC07 code to verify that this restriction has been met. and it is therefore up to the 
user to perform this check. In addition to the modified input file, the boundary data file 
must also be modified slightly. The boundary data file modifications apply only to inflow 
boundary specifications, specifically the boundary descriptor INLETG. At. present , only 
the INLETG specification may be used to properly define an inflow boundary in t he k — R 
solution. Since the k — lZ turbulence model is based on transport equations, it is necessary 
to properly specify the inflow values of k and 7v much in the same manner t hat other in- 
flow properties (total pressure, etc) must be specified. The inflow values for k and 7 Z are 
specified on the 2 lines follow ing the INLETG specification as shown in the example below: 


INLETG 1 1IIPPJK 1 1 1 73 1 2 1 73 1 2 

PTOT TTOT AKIN ARIN 

1.0 1.0 0.0001 0.001 

Here, the extra variables labeled as PTOT, TTOT, AKIN, ARIN are the inlet non- 
dimensional total pressure, total temperature, turbulent kinetic energy (k). and turbulent 
Reynolds number (Tv), respectively. Note that AKIN and ARIN are also input as non- 
dimensional variables using the non-dimensionalization scheme previously described. Typi- 
cal values of AKIN and ARIN are 0.0001 and 0.001. respectively. More accurate values for 
specific cases where detailed inflow turbulence characteristics are known can be determined 
based on the definitions of k and R. 

The modificat ions described above are all that is necessary to initiate the 2-equation tur- 
bulence model solut ion sequence. Unfortunately, only a limited amount of experience with 
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this turbulence model is available to guide the user in case a problem arises. The behavior of 
the partial differential equations can be monitored in both the standard output and conver- 
gence file iteration histories of maximum and RMS residual. Separate convergence history 
lines are tabulated by the A DPAC07 code for the k and R transport equations. This data 
is printed immediately following the continuity, momentum, and energy equation residual 
information at each iteration. It should be mentioned that the multigrid solution strat- 
egy employed to solve the continuity, momentum, and energy equations is not completely 
enabled for the k - R. transport equations. This is an area of algorit hmical research and 
may be completed in future releases of the ADPAC07 code. The “full** multigrid solution 
initialization sequence is available to rapidly initiate the k - R equation solution variables. 

The best practice found to date in employing the k — R solution scheme is to run the 
code with relatively small values ( TO) of the input variable CFL and run large numbers 
of iterations. The full multigrid start-up procedure has been found to be somewhat helpful 
(FFULMG=1.0). The k - R solution scheme converges relatively slowly, and make take 
2-2 time t he number of iterations as the algebraic turbulence model to completely converge. 
In addition, the cost of a given iteration when the k- R turbulence model is enabled may be 
up to 40% greater than a corresponding iteration using the algebraic turbulence model. It 
should be noted that there is no added numerical dissipation in the k — 7v solution scheme. 
A naturally dissipative first order upwind differencing is used in the discretization of the 
convective fluxes in the k — R equations. This implies that the input variables VIS2, 
VIS4 have no effect on the two-equation turbulence model solution sequence. Implicit 
residual smoothing is applied to the k — R equations, and therefore the variables CFMAX, 
EPSX, EPSY, EPSZ, FRESID can drastically alter the k — R convergence behavior. 
The k - R l solution scheme cannot currently be restarted which is a serious drawback for 
three-dimensional applications which require large amount of CPU time. Finally, upon 
completion, a PLOT3D based data file representing the mesh point -averaged data />. pl\ 
f)R . and p turbulent i s written to the file case w/mc.p3d2eq. This file, in conjunction with 
the ADFAC07 mesh file ( cast name .mesh ) may be employed to graphically examine the 
predicted turbulence characteristics of the flowfield. 

In the event that the k — R solution sequence diverges, or simply does not converge, 
the best known handle to stabilize the solution is controlled by the input variable CFL. 
Generally, lowering the value of CFL will help stabilize the solution. Unfortunately, this 
also decreases the convergence rate of the solution and increases the overall CPU time 
required for a given run. Limited experience with this model, and interruptions in the AD- 
FAC07 development schedule prevented a more thorough implementation of this promising 
model. 


3.17 Troubleshooting an AD PACO 7 Failure 

The A I) PA C 07 code contain a large number of error checking and handling facilities to 
determine and report to the user when a problem in the calculation occurs. Unfortunately, 
some problems simply cannot be detected and it may occur that for a particular case the 
solution will diverge (uncontrolled increase in solution residual) or simply “blow up** as a 
result of numerical difficulties or an invalid numerical operation (divide by zero for example). 
These cases are notoriously frustrating for the user because the cause is often difficult to 
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identify. The paragraphs below attempt to provide a structured approach to rectifying 
numerical problems for an ADPAC07 run based on the author's experience. 

Step 1.) Carefully Check the ADPAC07 Input File for Errors 

The .4 DPA C07 standard input file controls the overall characteristics 
of the computational process, and as such, plays a large role in determining the behavior 
of a job. Typical parameters to check are to make sure that the CFL variable is negative 
for steady state calculations, and positive for time- accurate calculations, and to make sure 
that the absolute value is not too large (5.0 is a typical magnitude). If the CFL value is 
greater than the CFMAX variable, or generally if the magnit ude of CFL is larger than 2.5. 
then residual smoothing must be activated (FRESID=1.0. the default value). Naturally, 
the values for VIS2 and VIS4 should also be within their suggested limits. A common 
problem for rotating geometries is an incorrect rotational speed, or simply the wrong sign 
on the rotational speed (rotating the wrong way), so check the values of RPM and/or 
ADVR carefully. The user can also selectively turn off features such as the turbulence 
model (see FTURBB) and/or multigrid (see FMULTI) to check on their influence on the 
stability of the solution. Finally, the user should make sure that the proper CASENAME 
and DIAM variables are specified in the input file. Other problems are discussed in the 
individual input file variable descriptions in Section 3.6. 

Step 2.) Carefully Check the .4 DP. \C07 Boundary Data File for Er- 
rors 

The A DPA CO 7 boundary data file cont rols the applicat ion of bound- 
ary conditions on the various mesh surfaces necessary to define the flow characteristics of 
an ADPAC07 run. Common errors in the boundary data file include mismatched PATCH 
specifications, incorrectly specifying inflow data (particularly when INLETT is used), and 
incorrectly specifying rotational speeds for solid surfaces using SSVI. If the solution will 
run for a few iterations, it may be helpful to get a PLOT3D output file at this point and 
examine the solution using PLOT3D or FAST. Check for obvious solution features such 
as flow going the right direction, flow that doesn't pen at. rate a solid boundary, contour lines 
matching at PATCH boundaries (although contour lines may not match exactly at any 
mesh corner), and obvious radical changes in flow variables (total pressures and/or total 
temperatures which are very large or negative). The user can often trace a faulty boundary 
condition by selectively commenting several specifications from the boundary data file and 
rerunning to see if the same problem occurs. If the solution diverges even when no boundary 
conditions are specified, then a problem exists in the mesh or input file. Other boundary 
condition specific common errors are discussed in the individual boundary data file variable 
descriptions in Section 3.7. 

Step 3.) Carefully Check the ADPAC07 Mesh File for Errors The 

immediate question to be answered when a mesh problem is suspected is “does the mesh 
file exist?". The user should verify the existance of the file with the proper name in the 
current working directory. The size of the file should be examined (obviously a file of length 
0 is unacceptable). The user can next check to make sure the file can be read with the 
PLOTS D [14] graphical plotting program. Any mesh file which has been created using 
the PLOT 3D binary file write option is not acceptable due to the format of the Scientific 
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Database Library (although it can be made so by appending 1024 bytes of any data to the 
end of the mesh file). The MAKEADGRII) program is available to convert unformatted 
mesh files to A I) PAC07 compatible mesh files. 

Most common problems encountered when the A DP A (7)7 code does 
not perform adequately can be traced to poor mesh quality. Although the mesh may be free 
from obvious Haws such as crossed mesh lines and/or zero volumes, this does not guarantee 
that numerical difficulties will be avoided. The most common overlooked features of mesh 
quality are the mesh expansion ratio and the mesh shear angle. Mesh expansion ratio 
relates to the change in physical mesh spacing along a given coordinate direction from one 
point to another. For stability, the maximum mesh expansion ratio at any point should 
not exceed 1.4. The A \)PAC07 code provides a listing of maximum mesh expansion ratios 
for each grid block and issues a warning if the mesh expansion ratio exceeds 1.4. The 
code can tolerate larger ratios in many cases, but definite problems can be expected if the 
maximum expansion ratio gets larger than 2.0. Mesh shear can also cause problems. The 
more orthogonal the mesh, the less likely mesh-induced numerical difficulties will occur. 
Another potential mesh problem involves mesh cells with very small radii (such as along a 
sting upstream of a propeller, etc.) which may require increasing the diameter of the sting 
to prevent problems. Application of the multigrid iteration strategy and reducing the value 
of EPSY in t lie input file have been found to be effective remedies for such problems. 

Step 4.) Check for the Possibility of an Invalid Flow Condition 

The author's experience has been that many users feel if a problem 
can be defined then it should possess a solution, in fluid dynamics this is certainly not 
true. If a solution is attempted for a fan rotor, for example, at a pressure ratio which is 
beyond the stall point for that rotor, then no solution exists and the code will very likely 
diverge without explanation. In many cases, the numerical equivalent of an invalid flow 
condition is that the solution will either not converge, or will simply diverge. Another 
common example is attempting to extract a steady state solution for a problem which is 
truly time-dependent. Blunt body flows often result in a time-dependent solution due to 
vortex shedding, and the steady state analysis of this flow will likely never converge. This 
behavior also occurs frequently when a strong adverse pressure gradient or flow separation is 
present in the solution. Now it is true that in some cases, the level of convergence may also 
be limited by such factors as mesh quality, numerical accuracy, and/or turbulence model 
limit cycles, and it is difficult to determine whether the cause is numerical or physical. This 
is unfortunately a matter of experience and the user is encouraged to question whether their 
case can truly have a “steady** solution. 


Step 5.) Determine if the Problem is Computer Dependent 

The ADPA( 7)7 code was developed and tested on UNIX-based oper- 
ating systems using FORTRAN 77 standard coding techniques. In spite of the standardiza- 
tion in the computer industry, not all machines produce the same answer for a given problem 
due to compiler optimizations and code handling features. It has been the author's expe- 
rience that compilers are often a source of problems, particularly when the code has been 
compiled for the first time on a specific architect lire, or when a new release of the operating 
system or FORTRAN compiler has been installed. Before reporting an unsol vable problem, 
it is a good practice to completely recompile the code on a known stable machine with a 
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well tested version of FORTRAN without using optimization (the user may be required to 
modify the ADPAC07 Makefile to do this). If the code displays the same error, then it is 
possible that a bug has been uncovered and this should be reported so future versions do 
not encounter the same problem. If the compiler supports static memory allocation, then 
this option should be enabled whenever possible. 

Step 6.) Determine the effect of key input variables 

Some u fme-t lining'’ of input variables is occasionally required to ob- 
tain a converged solution, or to prevent an instability from forming. The following sugges- 
tions may be useful to aid in establishing the sensitivity of the solution to various inputs: 


(j.l Try to run the problem for a few cycles without any boundary con- 
ditions. This is essentially a uniform flow test. If the code diverges, 
then the problem is either in the input file or the mesh. 

0.2 Vary the parameter CFMAX. Lower values imply more smoothing. 
It is possible to have too much smoothing, so both larger and smaller 
values should be tested. 

6.3 Make sure FRESID is set to 1.0 if the magnitude of CFL is larger 
than 2.0. 

6.1 Examine and vary the values of VIS2 and VIS4. 

6.5 Turn off all multigrid (FMULTI, FFULMG = 0.0). 

6.6 Turn off the turbulence model FTURBB = 999999999.0. If the 
problem still exists, try to run inviscid flow (FINVVI = 0.0). 

6.7 Clear the input file and boundary data file of all specifications (ex- 
cept the case name, which must be activated). Now. if the code 
diverges, there is almost certainly a problem with the grid. Examine 
the code output to determine where the maximum error occurs, and 
carefully check the grid in this region. 


Step 7.) Report the Problem 

In the event that no other cause of the problem can be detected, the problem should be 
reported to NASA. The recommended contact for problems (or successes) is: 


Dr. Chris Miller 
Mail Stop 77-6 
NASA-Lewis Research Center 
21000 Brookpark Road 
Cleveland, OH 44135 
(216) 433-6179 
cmillerOlerc . nasa . gov 


The author is also interested in keeping up with known problems and may be reached at: 
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Dr. Ed Hall 

Speed Code T-14A 

Allison Engine Company 

Indianapolis, IN 46206-0420 

(317) 230-3722 

ehallOnas . nasa . gov 

ieehl@agt . gmeds . com 
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Chapter 4 


RUNNING ADPAC07 IN 
PARALLEL 

4.1 Parallel Solution Sequence 

In order to run A l)P AC-07 in parallel. ADPAC07 must be compiled for parallel execution. 
The chapter on code compilation in this User's Manual describes the proper compilation 
procedure. 

ADPAC07 is parallelized using the Application Portable Parallel Library (APPL) mes- 
sage passing library, developed at NASA Lewis. Reference [22] explains how to write code 
using APPL and how to run codes written with APPL. While APPL runs on many plat- 
forms. this manual will deal with only two of them: workstation clusters and n(THK mas- 
sively parallel computers. These two platforms are representative of how ADPACQ1 runs 
in parallel. The APPL document should be consulted for cases not covered in this manual. 

Regardless of the platform, running ADPACOlxw parallel requires the APPL compute 
function and a procdtf file, ( odes running under APPL are not initiated by typing the 
executable name, but use the APPL compute function instead. The syntax for executing 
ADPAC07 is as follows: 

compute < case namt .input > output 

The compute function controls the execution of ADPAC01 on the various processors, 
taking addit ional input from the prordff file. The procdrf file contains the names of the 
executable images and the processors that they are to be loaded on. The compute func- 
tion establishes communicat ions with each processor specified in the procdcf file, loads the 
ADPAC07 executable image, and initiates the run on each processor. Also, the compute 
function oversees the running processes, monitoring the processors for abnormal termina- 
tions. If a communications error is trapped, or if a process has died unexpectedly, the 
compute function shuts down all of the remaining processes gracefully. This feature is 
most important on workstation clusters, which have no built-in mechanism for monitoring 
parallel jobs. 

The normal ADPAC'Q 7 input file is redirected from standard input to the compute 
function. The redirected input is available to all of the processes (although ADPAC01 cur- 
rently does all reading from node 0). The output file may be redirected, or allowed to 
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stream to the terminal, just as in serial. 

The procdef file should appear in the directory where the job is being run. It lias a 
different syntax for the various parallel platforms. The simplest formulation is for hvpercube 
machines (nCUBE and Intel). A sample procdef file for an nCUBE 2 is as follows: 

someuser frntend . . /adpacp .ncube -1 32 

The first token in the procdef file is the user name (someuser). The second token is 
the name of the front-end processor to the nCUBE 2. The third token is the path to 
the directory for input and output files (in this case, the current directory, is used). 
The fourth token is the executable name (the path may be specified to be sure the correct, 
executable is used). The fifth token specifies how the processors are mapped (-1 indicates 
hypercube ordering. -2 indicates mapping into a ring). Hypercube ordering is generally 
preferred. The last token specifies the number of processors to be allocated (32 in this 
case). 

Similarly, a sample procdef file for a workstation cluster is as follows: 

someuser hostl . 1 adpacp. aix 

someuser host2 . 1 adpacp. aix 

someuser host3 . 2 adpacp . aix adpacp . aix 

In this example, the first three tokens represent the user name, host name and the path 
to the working directory, just as before. The fourth token indicates the number of processes 
to be run on the host, and the remaining tokens are the executable images corresponding 
to the processes. The last line of the example shows 2 processes running on host 3. Using 
this procdef hie. the virtual parallel computer will consist of four processes running on three 
workstations. 

The host machines in a workstation cluster must be connected bv ethernet, but do not 
have to share disks, or be part of the same subnet. This provides tremendous flexibility in 
constructing a workstation cluster. However, most performance bottlenecks encountered on 
workstation clusters involve the network. The benefits of adding processors may be offset 
by poor network performance. The tradeoff varies with the problem and with the hardware 
configuration. 

In general, the behavior of ADPAC07 in parallel is the same as in serial. This is 
especially true if there are no input errors. The output files may be different if there are 
input errors. There are two general types of input errors detected in ADPAC'07 . Errors 
involving the grid or the input file will generally be detected by all processors, and t he error 
messages will appear as they do in serial. 

If. however an error is discovered in a boundary condition routine, the output messages 
will probably appear differently in the output file, and may not appear at all. Since AD- 
PAC'07 boundary conditions are applied in parallel, node 0 does not execute all of them, 
but only those involving a block assigned to node 0. If node 0 does not encounter the error, 
then a different node writes the error message. Since the writing node is out of sync with 
node 0, the error message may be written to a different place in the output file than if node 
0 had written it. 
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Buffering of output on the various processors can also cause a problem. Usually, after 
an error message is printed, execution is stopped on all processors. If execution is stopped 
before the buffer is flushed, then output may be lost from some processors. The result is 
that an error message could be caught in the buffer and never appear in the output file. If 
ADPAC01 terminates for no apparent reason, this may explain the problem. The solution 
is to rerun the job without redirecting the output. If out put is not redirected, it is normally 
not buffered, and all of the output will appear. 

It is also possible to get multiple copies of an error message if more than one processor en- 
counters the error. Wherever possible. ADPAC07 has been coded to avoid these problems, 
but these unfortunate possibilities still exist. Therefore, running AI)PAC 1 07 interactively 
is the best way to track down input problems. 

Aside from these considerations, running ADPAC07 in parallel is very much like running 
ADPAC07 in serial. The input files are identical, and the output files are very similar. The 
most common problems in running .1 DPA CO 7 in parallel are failing to use the compute 
function, improperly specifying the parallel configuration in the proedef file, and attempting 
to run a serial executable in parallel. 


4.2 SIXPAC (Block Subdivision) Program 

SIXPA(' , which stands for Subdivision and Information eXchange for Parallel ADPAT 
Calculations, enables the user to redefine the block structure of an ADPACV7 job. Using 
SIXPAC . large grid blocks can be subdivided to improve load balance, or to make use of 
smaller memory processors in parallel calculations. SIXPAC 1 generates new input, mesh, 
restart, and boundata files for the subdivided problem, creating new blocks according to 
user specifications. The resulting files represent a problem equivalent, to the original, but 
with more, smaller, blocks. Although the number of unique grid points is unchanged, the 
total number of points is larger because of duplication at interfaces. 

The motivation for SIXPAC 1 comes from the way A DPA CO 7 was parallelized. Rather 
than parallelize the interior point solver, ADPAC07 was parallelized through the boundary 
conditions. An individual block can't be run across multiple processors; each processor must 
contain only whole blocks. This implies that a problem with a single large block couldn't 
be run in parallel. SIXPAC 1 enables large blocks to be recast as groups of smaller blocks, 
so that they can be run in parallel. SIXPAC 1 is not required to run a problem in parallel, 
but it simplifies the process of setting up a problem for optimal parallel performance. 

4.2.1 SIXPAC 1 Input 

The input- files required by SIXPAC 1 are the casenenne .input file, the rase name .mesh file, the 
case name .benrndata file, and the cast name .sixpac file. If a new restart file is to be created, 
then a cast name .restart. old file is also required. Of this group, only the case net me.six/mc 
file is different from the standard ADPACO 7 input. 

The case name .sixpac file cont ains information which specifies how t he blocks are to be 
subdivided. The required information includes the number of original blocks, and how- 
each block is to be subdivided in each indicia! direction (i, j. and k). In each direction, 
the number of subdivided blocks, and possibly the locations of the subdivisions, must be 
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specified. If the number of subdivided blocks in a particular coordinate direction is set to 
1, then the block is not divided in that coordinate direction. 

By default, blocks are split into the specified number of equal sized pieces. If there is a 
remainder, it is spread over the processors to create nearly equal sized pieces. If unequal 
divisions are required in a particular direction, then the location of each division must be 
specified in that direction. 

Unequal divisions are often employed to preserve levels of multigrid, or to put the edge of 
a geometric feature on a block boundary. Figure 4.1 illustrates how different block strategies 
affect multigrid. If, for example, there are 21 points in the I direction of a block, 3 levels of 
multigrid are possible. If this block is divided into two equal pieces of 11 points each, then 
only 2 levels of multigrid are possible. However, if the block is split into a block with 13 
points and a block with 9 points, 3 levels of multigrid are still possible. 

4.2.2 casenarnf .sixpac File Contents 

For equal divisions of the blocks in each direction, the case name ..sixpac is simple to construct. 
The first line is a comment, and the second line contains the number of blocks in the original 
problem. Input is free format. The third line is a comment, and there is an additional line 
for each original block, in ascending order. These lines contain the block number, and 
the number of subdivided blocks in each coordinate direction. The following is a sample 
ra sena in t . s ixpa c fi le : 


Number of blocks 
2 

n idiv jdiv kdiv 

1 4 2 1 

2 4 2 1 

In this example, there are two original blocks. The first block is to be divided into 4 
pieces along the I coordinate, 2 pieces along the J coordinate, and 1 piece along the K 
coordinate. The second block is to be divided into 4 pieces along the I coordinate, 2 pieces 
along the J coordinate, and 1 piece along the I\ coordinate. This means that there will be 
a total of 16 new blocks generated from the original 2 blocks. 

If. however, user-specified divisions are required in a direct ion, the ease name .sixpac file 
must be modified as follows: 

• The number of subdivided blocks in the direction to be specified is set to 0. This tells 
SIXPAC that user specifications are to follow. 

• New lines are added to the casename. sixpac immediately following the block to be 
modified. First, a comment line is added, which normally identifies which direction is 
being specified. Second, a line containing the number of subdivided blocks is specified 
(either nblki, nblkj, or nblkk, depending on the direction). Third, a comment line is 
added, which normally indicates that the following line contains block division points. 
Fourth, lines are added containing the division positions for the new blocks. There 
should be nblki, nblkj, or nblkk of these entries, as specified above, in free- format. 
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Subdivision of Blocks to Preserve Levels of Multigrid 



1 11 21 


Subdivision into two equal pieces results in blocks with 1 1 points. Only two 
levels of multigrid are possible, even though three levels were possible for 
the original block. 



1 13 21 


Subdivision into two unequal blocks, one with 13 points and one with 9 
points, yields a grid capable of three levels of multigrid, like the original 
block. 


F igure 1.1: Careful block division can preserve levels of multigrid. 
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• The block division positions are the upper limits of the new blocks in terms of the 
original block indices. The last division should be the block size in that direction. 

• Block division positions must be specified in ascending order. 

• If user-specified subdivisions are required in more than one direction of a single block, 
then the additions are made in “natural order." that is I first, then J and K, as required. 

• All blocks must appear in the cast name. sixjxir file in ascending order. 

SIXPAC lias some sanity checks built in to warn users of problems in t he casenamt .sixjmc 
file. A sample rase narne.sixjxic file appears below. (Note: free format input so alignment 
is not important ). 

Number of blocks 
2 

n idiv jdiv kdiv 

1 4 0 1 

number of J divides 
2 

J break points 
3 10 

2 4 2 1 

As before, there are two original blocks. The first is to have 4 I divisions, 2 J divisions 
and 1 K division. The J divisions are to be at .1 = 3 and J = 1 0 in block 1. The second block 
is to have 4 I divisions 2 4 division and 1 I\ division. This means that there will be a total 
of 16 new blocks generated from the original 2 blocks. 

4.2.3 Restart Files in SIXPAC 

If a restart file is to be created for the subdivided problem, the input trigger FREST 
must be set equal to 1.0 in the rase name, input file. This tells SIXPAC ' to look for a 
case name. rx start, old file, and to subdivide it. A N case name, re start, old file is written, and 
the new input file will be set up to run with the new restart file. 

4.2.4 SIXPAC ' Output 

The output files produced by SIXPAC are the X case name. input file, the N case nanu .mesh 
file, the Xcasf nanu .boundata file, and the N rase name, bar par file. An Ncasf name, restart, old 
file is also created if required. The casename has been prepended by an “N" to avoid 
confusion with the original input files. The new output files are themselves ADPAC01 input 
files and can be run in either serial or parallel versions of ADPAC07 . 

The N rase name, bacpar file is not required to run ADPAC07 . but is used by t he code 
BA( % P AC , which reassembles the blocks into their original, undivided structure. The 
Ncasf name . bacpar file contains informat ion about t he way SIXPAC 1 subdivided the blocks. 
There is normally no reason for the user to alter the N rase name, bar par file. The form 
of the Ncasenaine. bacpar is described in the section of the User's Manual dealing with 
PACPAC 1 input. 
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4.2.5 Running SIXPAC 

Running SIXPAC 1 is very much like running ADPACV7 . The command syntax is: 

sixpac < case name. input > output 

The output file is similar to an ADPAC07 output file, because the routines to read the 
grid, the input file and the boundary data file are taken directly from ADPACV7 . One 
addition to the output file is a table of the new grid blocks and their sizes. After verifying 
the new block structure created by SIXPAC f . the output file can be discarded. 


4.3 BACPAC 

BAC'PAC 1 . which stands for Block Accumulation and Consolidation for Parallel ADPAC 
Calculations, reassembles subdivided ADPACO 7 files into their original, undivided form. 
It is used in conjunction with SIXPAC 1 , and performs essentially the inverse operation of 
SIXPAC 1 . BACPAC can reconstruct mesh, PL0T3D, or restart files, producing new files 
which are equivalent to what would have been produced had the problem been run with the 
original, undivided blocks. Using SIX PA C and BACPAC 1 , a problem can be subdivided 
and reconstructed any number of ways to take advantage of available computer resources. 

4.3.1 BACPAC Input 

BACPAC queries the user for needed information, and reads from standard input (normally 
the keyboard). The user is first prompted for the casename. The user then selects which 
files are to be reconstructed by entering appropriate responses to questions about each file. 
Due to the potential size of these files, they are not created by default. 

BACPAC 1 expects to find a case name .bacpac file which contains information detailing 
how the original problem was subdivided. The casename .bacpac file is created automat ically 
by SIXPAC 1 , and requires no modifications by the user. However, if SIXPAC 1 was not used 
to create the subdivided blocks, the user must construct a case name .bacpac file in order to 
run BAC'PAC 1 . A sample case name .bacpac file resulting from the first sample SIX P.4 f input- 
file given previously appears below. 

2 original number of blocks 


imax 

jmax 

km ax 







73 

10 

9 







nblki 

nblkj 

nblkk 







4 

2 

1 







oldblk 

newblk 

global i 

global j 

global k 

local im 

local jm 

local 

km 

73 

10 

9 







nblki 

nblkj 

nblkk 







4 

2 

1 







oldblk 

newblk 

global i 

global j 

global k 

local im 

local jm 

local 

km 


In the above example, two blocks are subdivided into eight new blocks each (a total of 
l(j blocks). The dimensions of the original blocks are 73.rl0.r9. and there are 1. 2. and 1 
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subdivided blocks in each coordinate direction for each block. The table underneath each 
of the original block size declarations shows the original block number, and the new block 
number. The global i, j, and k indices are the position of the bottom right hand corner of 
the new block in the original block. For example, the point (1,1.1) in the new block 8 is 
the same as the point ( 17,9,9) in the original block 1. The local im, jm, and km indices are 
the block size of the new block. This data essentially maps the new blocks into t he original 
block structure. 

4.3.2 BA CPA C Output 

The output files produced by BACPAC are the Ncasenarne.nush.bae file, the Ncase- 
fiamt.p3dabs.bac and the N case name. pSdreLbac files, and the Ncasenanu .n start .bar file. 
The .bar suffix is used to avoid confusion with existing files. Generally the Ncasename. mesh. bar 
need not be created because it is identical to the original case name. mesh file. If success- 
fully run and converted, the Ncasenanu . *.bac files should replace their original problem 
equivalents (casenanu .*) before starting SIXPAC again. 


4.4 Parallel ADPAC01 Block/ Processor Assignment 

Load balancing is a critical issue for parallel computing tasks. While it is beyond the 
scope of this program to perform detailed load balancing analyses for every parallel com- 
puting platform tested, it seems reasonable to provide some form of control in order to 
distribute computational tasks efficiently across a parallel computing network. In the par- 
allel ADPAC07 code, this is best accomplished through manipulation of the block/processor 
distribution scheme. By default, the parallel operation of the ADPAC'Ql code provides an 
automatic block to processor assignment by dividing up the blocks as evenly as possible, 
and. to the greatest degree possible, assigning sequential block numbers on a given proces- 
sor. For example, if 8 blocks were divided between 3 processors, blocks 1, 2. and 3 would be 
assigned to process #0. blocks 4, 5. and 6 to processor #1. and blocks 7. and 8 to processor 
#2 (note that the processor numbering scheme is 0. 1, 2, etc.). This procedure is nearly 
optimal when each block is the same size, and each processor has the same computational 
power. Unfortunately, our experience is that block sizes and computational resources often 
vary dramatically. In this regard, a system was developed which permits the user to specify 
the block to processor assignment through a special input file (case name. blkproc). A sample 
casf name .blkproc file is given below for an 8 block mesh dist ributed across 3 processors: 


number of blocks 


8 

block # 
1 
2 

3 

4 

5 

6 


proc # 
0 
1 
1 
1 
1 
2 
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7 2 

8 2 

In the case described by the above file, block 1 is assigned to processor #0. blocks 2. 3, 
1. and 5 to processor #1. and blocks (>, 7, and X to processor #2. This block assignment 
might be advisable for the case when block I is significantly larger in size than the other 
blocks, or if processor #0 has less memory or a. slower CPU than the remaining processors. 
The original block assignment scheme is selected as the default when the cast nann .blkproc 
file is not present. 
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Chapter 5 


MAKEADGRID PROGRAM 
DESCRIPTION 


The standard distribution for the ADPAC07 program includes a program called M AKKAD- 
(ilill) which aids the user in setting up a multiple-block mesh file from isolated unformatted 
mesh files. This program is useful for creating A DPAC07 compat ible mult iple-block meshes 
from mesh generation programs which do not support the use of the Scientific Database 
Library (SDBLIB). The MAKEADGRID program is an interactive program which queries 
the user for t he number of blocks to be assembled for the final mesh, and then requests a 
file name for each of the individual mesh blocks. The user is then requested to name the 
final output file for the ADPA('()7 compatible multiple-block mesh. The individual mesh 
blocks are assembled in the order in which the mesh file names are specified, so care must 
be taken to order t hese names appropriately. 


5.1 Configuring MAKEADGRID Maximum Array Dimensions 

Maximum array dimensions in the MAKEADGRID program are set by the FORTRAN PA- 
RAMETER statements listed in t he source file makeadgrid.f included with the standard 
distribution. The PARAMETER statement and the descriptions of the various parameter 
variables appear at the top of the file as: 

C 

C 

C makeadgrid: This program assembles an ADPAC-compatible mesh file 
C from selected other unformatted PL0T3D mesh files 

C 
C 

C Set parameter size for max grid block to be read in 
C 

C imax > maximum number of grid elements in the i coordinate direction 

C for any given mesh block 

C jmax > maximum number of grid elements in the j coordinate direction 
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C for any given mesh block 

C kmax > maximum number of grid elements in the k coordinate direction 

C for any given mesh block 

C nnames - > maximum number of grid blocks for final mesh 
C 

parameter (imax=251 , jmax=82, kmax=53) 
parameter (nnames = 100 ) 


5.2 Compiling the MAKEADGRID Program 

The MAKEADGRID program source directory contains a UNIX-based Makefile facility to 
automate compilation for a number of machines. In the directory containing the FORTRAN 
source of the MAKEAD GRID code, compilation is performed by executing the command: 

make option 

The make command is standard on UNIX systems and automatically interrogates the file 
Makefile for instructions on how to perform the compilation. The option argument may be 
any of the variables listed below: 

No argument - same as link below. 

link This is the standard UNIX system compilation. This option will 
deliver a working executable on most UNIX systems which support 
standard naming conventions (f77 as the standard compiler, etc.). 
The compilation includes basic compiler optimization (177 -0). 

cray This option is utilized when compiling the standard code on a ('ray 
computer. 

air This option is used when compiling the standard code on an IBM 
RS-6000 workstation running the AIX operating system. 


5*3 Running the MAKEADGRID Program 

Once the code has been compiled, change directories to the location where the case of 
interest has been stored. The MA K EA DC RID program requires that each individual mesh 
block for the final mesh be stored separately as a single-grid unformatted PLOT 3D file . 

The MAKEADGRID program is invoked by issuing the command: 

path / makeadgr id 

where path is the relative or absolute pathname of the directory containing the MAKE A D- 
GRID executable file from the current local directory. For example, if the mesh file is in 
the directory 
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/usr /people/me/ test case 

and the I A I\ KA DC1IIID executable is in the directory 
/usr/people/me/adpac/ src/makeadgrid 
then the commands 
cd /usr/people/me/testcase 

/usr/people/me/adpac/src/makeadgrid/makeadgrid 
would begin t he MA I\PA DdRID program process. 


5.4 Sample Session Using the MAKEADGRID Program 

A sample session using t he MA KEA DdRID program for the mesh illustrated in Figure 2.1 is 
given below. In this case, the mesh was originally generated using a proprietary mesh gener- 
ation program, and hence, required some manipulation in order to construct the multiblock 
mesh for an A DPA C07 solution. The mesh consists of 3 mesh blocks (the O-grid about the 
airfoil, and 2 11-grid caps upstream and downstream of the O-grid) named blockl.mesh. 
block2.mesh, and block3.mesh. The MA A EADGRID session used to create the final 
mesh named vbivane.mesh is listed below. The user responses to the MAhhADCIt ID 
program are given in boldfaced type. 

************************************************ 

MAKEADGRID - construction program for 
creating ADPAC mesh files 
from selected PL0T3D unformatted 
mesh files . 

************************************************ 


Enter the number of blocks 


3 


Enter the name of the 


1 grid to process 


(Remember: each file must be unformatted PL0T3D style 
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blockl.mesh 

Enter the name of the 2 grid to process 

(Remember: each file must be unformatted PL0T3D style 

block2.mesh 

Enter the name of the 3 grid to process 

(Remember: each file must be unformatted PL0T3D style 

block3.mesh 


Getting grid sizes and 

extra info 

from grid files 



Loop= 

1 mg= 
33 

0 

il, jl,kl= 

129 

33 

Loop= 

2 mg= 
17 

0 

il, jl,kl= 

17 

33 

Loop= 

3 mg= 
17 

0 

il.jl.kl* 

17 

33 


Enter the file name for the final grid 
vbivane.mesh 


Final grid data in file 
vbivane.mesh 


Output file array size 


Loop = 

1 — > 

129 

33 

33 

Loop = 

2 — > 

17 

33 

17 

Loop = 

3 — > 

17 

33 

17 


Array sizes output to final file 
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Reading Grid Data from file 
blockl .mesh 

il, jl, kl — > 129 

Output grid data to final file 
Reading Grid Data from file 
block2 .mesh 

il, jl, kl — -> 17 

Output grid data to final file 
Reading Grid Data from file 
block3 .mesh 

il, jl, kl — > 17 

Output grid data to final file 


PROGRAM COMPLETED NORMALLY 
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ADPAC07 INTERACTIVE 
GRAPHICS DISPLAY 


The AI)PA('07 program is equipped with an option which permits real time interactive 
graphics display of flow data in the form of colored contours or velocity vectors on geometries 
represent ed by wiremesh grid surfaces. The interact ive graphics are based largely on rout ines 
generated from the P LOT'S l) visualizat ion program, and many of the features of this option 
should he familiar to anyone who has used PLOTS !) . All interactive graphics must be 
displayed on a Silicon Graphics workstation. IRIX Operating System 1.0.1 or above. The 
graphics display can be operated on a single computing platform, or can be directed across 
a network for specific computer hardware configurations. Thus, it is possible to have a 
job running remotely on a Cray computer, with interactive graphics displayed locally on a 
network-connected Silicon Graphics workstation. When operating across a network which 
involves a non-Silicon Graphics computer, the communication program AGTPLT-IA'L must 
be running on the local display device in order to capture the graphics commands issued 
by the remote compute server (details on AGTPLT-LCL are given below). A graphic 
illust rating the possible graphics display operating modes is given in Figure (j. 1 . It should be 
mentioned that the interactive graphics display was actually developed to aid in debugging 
the multiple block code. The description of this feature is included in this manual for 
completeness, but the user should be cautioned due to the immature nature of this portion 
of the code. It is also likely that the graphics option may not port correctly to future 
releases of the IRIX operating system, and again, the user is cautioned concerning the use 
of this feature. 


6.1 Setting up the Program 

The first step in producing the real time interactive graphics display is to correctly compile 
the code to include the graphics libraries. This is accomplished by utilizing the appropriate 
option in the A DPA C07 Makefile command (see Section 3.4). The valid graphics options 
include graphics. pf agraphia s. craygraphics. air graphics, and craygraphdbx. These options 
incorporate various levels of the included graphics libraries for execut ion on various machines 
(again, see Section 3.4 for specific Makefile details). 

Once the code has been correctly compiled to include the graphics libraries, several input 
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ADPAC Interactive Graphics Display 
Computer Network Configuration Options 



ADPAC execution and graphics 
display on Silicon Graphics Workstation 

(Code compiled with graphics option) 


ADPAC execution on 
Silicon Graphics Workstation 

(Code compiled with graphics option) 


Ethernet 



Graphics display on a network-connected 
Silicon Graphics Workstation 


Graphics Transmission via X -Windows 
Display System 


ADPAC execution on 
remote (non-Silicon Graphics) 
Computer 

(Code compiled with CGL 
libraries) 



Graphics display on a network-connected 
Silicon Graphics Workstation 

(AGTPLT-LCL must be running on 
this machine) 


Graphics Transmission via UNIX socket communication 


Figure 6.1: ADPAC07 interactive graphics display network configuration options 
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parameters must he correctly initiated to engage the graphics subroutines during the exe- 
cution of the code. The input keyword FGRAFIX must have a value of 1.0 to initiate any 
graphics instructions. The keyword FGRAFINT determines the number of time-marching 
iterations between graphics window updates. The keyword FIMGSAV is a trigger (0.0 
- off. 1.0 - on) which determines whether periodic image capturing is enabled, and the 
keyword FIMGINT determines the number of time-marching iterations between image 
captures. Additional details concerning these input file keywords are available in Section 

6.2 Graphics Window Operation 

Once the graphics window has been initiated on the local display, and the initial data 
has been plotted, the program continues and the graphics display data are updated every 
FGRAFINT ite rations. This process will continue until the program terminates, or until 
the user interrupts the process by pressing the left mouse button once with input focus 
directed to the graphics display window'. A short time later, (the delay may be quite long 
for a network which is burdened), the graphics display will freeze, and the computational 
portions of the program will be suspended in order to permit- the user to interactively 
translate, rotate, or scale the graphics image to their liking. When the display has been 
frozen, t he viewpoint of the display may be alt ered by one of several mouse cont rols. The left 
mouse button controls rotation, the right mouse button controls translation, and the middle 
mouse button controls scaling (zoom in. zoom out). The controlling mouse movements are 
illustrated in Figure (j.2. The mouse-directed viewpoint controls are identical to those used 
in PLOT-ID [14]. Once the viewpoint, has been altered, program control is returned to 
ADPAC07 by hitting the ENTER key on the keyboard with input focus directed to the 
graphics window. At this point, the code will then return to the process of performing 
time-marching iterations, with periodic updating of the graphics screen. 

It is also possible for the user to change the plotting function by entering any one of the 
following characters with input focus directed to the graphics window’ at any time during 
t he process: 

Key Result 

p Set flow' function to pressure contours 

2 Set flow function to velocity vectors 

The surfaces plotted by the interactive graphics display is currently hardwired in the code. A 
wircmesh representation and the corresponding surface contours are generated for the /= 1. 
j— 1 , and A*= 1 mesh surfaces. This restriction could be removed in future developments. 


6.3 AGTPLT-LCL Program Description 

The program AGTPLT-LCL is the receiving program for local graphics display of an AD- 
PAC07 job running on a remote, network-connected computing platform. The AGTPl/T- 
LCL program is a modified version of the NASA-AMES developed PLOT3D-LCL program. 



240 


ADPAC07 Interactive Graphics Display 


ADPAC Interactive Graphics Display Mouse Control 



Figure 6.2: ADPAC07 interactive graphics display mouse control 
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This program can only ho run on a Silicon Graphics Workstation running at level 4.0.1 
(or above) of the IRIX operating system. As such, compilation of the AGTPLT-LCL pro- 
gram has no options, and is performed simply by executing the command make in the 
AGTPLT-LCL source directory. Once initiated, the AGTPLT-LCL program waits for an 
outside process from ADPAC-07 to communicate with the local workstation, and graphics 
commands received from the remote job arc displayed locally. 

An important consideration in setting up a remote calculation with local graphics display 
using AGTPLT-LCLis the manner in which the local display is defined in the calculation. 
The GGL libraries used to permil the network graphics instructions require an internet 
net work address in order to properly transmit the graphics commands to the correct desti- 
nation. This definition should be provided in the standard input file following the normal 
keyword parameters (see Section 3.(j for a sample file and keyword definitions). At the end 
of the standard input keyword data, the user should use an ENDINPUT statement to 
terminate the normal input stream. The ENDINPUT statement should then be followed 
by two blank lines, and then a line containing the destination network address of the lo- 
cal Silicon Graphics display device. This specification will ultimately be read by the CGL 
libraries in setting up the network connection. 

The procedure to set up t his network-connected graphics display option would be to start the 
job on the remote machine, and then immediately start the A GTPLI - L( L program on the 
local display. As long as the correct network address has been entered in the cast. input file, 
then the remote program should begin communicating with the AG TPL T-LCL program, 
and the local graphics window will begin displaying the graphics instructions specified by 
the remote computing program. 
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ADPAC07 TOOL PROGRAMS 
DESCRIPTION 


The standard distribution for the ADPA('07 program includes a number of tool programs 
designed to assist in examining and manipulating data generated for an A DPA ('07 solu- 
tion. Although running these programs is generally self-explanatory, a brief description is 
provided below to outline the function of each tool program. 


7.1 ADPERF Tool Program Description 

The ADPERF tool program was designed to provide a simple post processing program 
for computing overall integrated thrust and power coefficients for unducted fan (propeller) 
calculations based on a simple H-type mesh discretization strategy (see Standard Con- 
figuration $ 1 in Chapter 5). Upon execution, the ADPERF program asks the user to 
input the name of the ADPAC07 mesh and restart files for the run of interest. The 
ADPERF program then opens and reads both files, and attempts to estimate the num- 
ber of blades in the propeller which the user must then verify (presumably the mesh 
represents only a single blade passage of the overall geometry). Following this, the AD- 
PERF program asks for the value of the ADPAC07 nondimensional parameters RHOO and 
OMEGA. These values are identified in the ADPACO 7 output file under the following head- 
ing: 


non-dimensional initial values calculated as: 
******************************************** 


rhoO 

( initial density 

) = 

.8498 

uO 

( initial axial velocity 

) = 

.6643 

vO 

( initial radial velocity 

) = 

.0000 

wO 

( initial theta velocity 

) = 

.0000 

eiO 

( initial internal energy 

) = 

2 . 5630 

hO 

( initial enthalpy 

) = 

3.5000 

pO 

( initial pressure 

) = 

.7962 

to 

( initial temperature 

) = 

.9370 



244 


PATCH FINDER Tool Programs Description 


dmuO ( initial viscosity ) = .0000 

omega ( rotational speed ) = -.0096 < 

The final parameter to be entered is the propeller diameter in grid units (if the mesh is 
in feet, enter the propeller diameter in feet). Following this, the .4 DPERI program will 
compute the propeller power and thrust coefficients based on blade static pressure loading. 


7.2 ADSTAT Tool Program Description 

The ADSTAT tool program was designed to provide statistical information about a mesh or 
flow (PLOT31) output ) file from an ADPAC0I run. Upon execution, the ADSTAT program 
asks the user to select whether information about a mesh file (m) or flow file (f) is desired. 
In either case, the user is then asked to input the appropriate mesh or flow file name. If 
the mesh file option is selected, the ADSTAT program opens the mesh file and reports 
the number of mesh blocks contained within the file, as well as the individual mesh block 
sizes. The ADSTA T program also computes the maximum allowable number of multigrid 
levels (based on mesh size alone) which can be used for an ADPAC07 run. In addition, 
the ADSTAT program computes and reports the minimum required ADPAC01 array size 
parameters for all allowable number of multigrid levels. This capability is the most useful 
feature of the .4 DSTAT program. If the flow file option is selected, in addition to the above, 
the extra flow file data (standard in the PLOT3D file format ) is also reported for each block 
(normally this includes the Mach number, angle of attack, Reynolds number, and time). 


7.3 AOA2AXI Tool Program Description 

The .4 O.l 2,4 A7 tool program was designed to compute an axisymmetric average of a 3-D 
cylindrical coordinate system solution. The program is restricted to H-tvpe meshes similar 
to standard configurations #1-3 and in Chapter 5 which possess uniform axisymmetric 
projections on each mesh plane in the circumferential direction (this simplifies the averaging 
process). When running AOA2AXL the user is requested to enter the 3-D mesh and flow 
(PLOT3D format) file names. Then, the user is offered the option of redimensionalizing 
the data, and finally, the user is requested to enter the 2-D axisymmetric mesh and flow 
(PLOT3D format ) file names. The A OA 2/1 A7 code computes the axisymmetric average of 
the 3-D mesh and flow file data and stores the result in the 2-D axisymmetric mesh and 
flow files. These data may then be used with PLOT3D and other graphics visualization 
tools to examine the axisymmetric average of the 3-D solution. 


7.4 PATCHFINDER Tool Programs Description 

An ADPAC07 utility program was developed to aid in the construction of boundary condi- 
tion files for complex, interconnected multiple block mesh systems. The new utility, named 
PA TCHFINDER . reads in an ADPAC07 mesh (a PLOT3D binary multiple-block grid) and 
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determines which blocks share matching faces. As the grid is read, the faces are striped off 
into a separate array. Individual points on these faces are compared until a “point" match is 
found. Neighboring points are then compared to find a “cell" match. This also determines 
the relative directions of the matching indicies. From this cell match, a common face area 
is swept out and a PATCH boundary condition statement is written using the bounding 
indicies of the common face area. 

After all the PATCH specifications have been written, any remaining surfaces not ac- 
counted for will have a solid surface wall (SSVI) boundary condition written out. This 
allows the user to simply replace a few solid wall statements with the proper inlet and exit 
boundary conditions and start running. The PA TCUFINDER user input file contains ap- 
proximately ten variables to customize a PATCH FINDER run to each grid although many 
grids can be processed without special input. Since the majority of boundary conditions 
prescribed in most geometries are block patches and solid walls, running PATCH I INDER 
will great ly simplify the generation of a boundary data file. 

Several methods were implemented to accelerate the PATCH FINDER search and compare 
process. Some of these methods include using multi-grid and bounding cube limits. If 
a mesh is created to be run with ADPAC07 using multi-grid, this can also be used to 
accelerate PA T('HFINI)ER since boundary condit ions must be consistent across multi-grid 
levels. Each level of multi-grid decreases the number of face points by a factor of 4: t herefore, 
with 3 levels of multi-grid a decrease in run time of roughly sixteen times can be expected. 
The bounding cube limit method creates a limiting cube enclosing all the cell centers of 
a block face. Before any individual face points are checked, the corresponding bounding 
cubes are checked for intersection. If the cubes do not intersect, then no matching points 
are possible; this greatly reduces the number of individual point searches. 

Several test cases were run using PA TC I! FINDER. These included both 2-1) and 3-1) geome- 
t lies with and without multi-grid. Each of these runs was timed to evaluate the efficiency 
of the program. The resulting approximate wall clock times are shown in the table in Fig- 
ure 7.1. All cases were run on the same machine under similar conditions so that relative 
comparisons can be made. Most of the test cases using multi-grid finished in under two 
minutes. One of the largest and most complex test cases was based on a mesh with over 
1S0.000 points and over 800 mat ching faces. PATCHF INDER was able to correctly identify 
all the patches in under 17 minutes (on a Silicon Graphics 4D-35 workstation) as opposed 
to the approximately two days required to correctly specify the PATCH connections by 
hand. The PA I ( 'HFINDER time was limited in t his case since the grid contained only one 
level of multi-grid. From the times recorded in the table, the advantage of using multi-grid 
becomes apparent. 


7.5 PLOT3D Tool Programs Description 


A number of tool programs originally generated for the PLOTSD program are included with 
the ADPAC07 distribution because of their usefulness in manipulating ADPAC’07 mesh 
and flow (PLOT.'ID output format) files. A brief description of these codes is given below. 
It should be noted that most of these programs are designed to deal with unformatted 
files, rather than the ADPAC07 standard binary format. Fortunately, the PLOTSD or 
BIS2VNF tool programs can be used to convert from ADPAC07 binary to unformatted. 
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Test Case Grid 

Grid 

Points 

Block 

Faces 

Multi-Grid 

Levels 

PATCH(es) 

Written 

Elapsed 

Time 

2-D Axisymmetric 

Seal Cavity (Phadke/Owen #5) 

5,438 

36 

3 

12 

m 

0-Grid Capped 
with H-Grids 

34,595 

18 

1 

16 

11:14 

Combustion Can 


72 

3 

72 

0:07 

Exhaust Mixer 

197,190 

36 

2 

22 

1:23 

Vane Blade Interaction 

232,645 

30 

3 

30 

0:19 

Rotor-Stator-Rotor 
with Seal Cavity Grid 
(Unsteady, Multiple Pitches) 

259,777 

258 

2 

214 

1:05 

Airplane 

483,876 

618 

1 

808 

16:31 

AE3007 Fan with 
5-Groove Casing Treatment 

642,479 

21 

3 

50 

1:46 

Rotor-Stator-Rotor 
with Seal Cavity Grid 

715,001 

90 

3 

62 

1:44 


Figure 7.1: Approximate wall clock run times for various PATCH TINDER test case config- 
urations. 
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and the MAKEADCIRTD program may be used to convert from unformatted format to 
ADPAC01 binary. 


• CHOPQ (bit a subset out of a (31), single grid) PL0T3I) Q file and write it out as 
a new Q file. 

• CHOPX (bit a subset out of a (31), single grid) PL0T3I) XYZ file and write it out 
as a new XYZ file. 

• CHOPXB (bit a subset out of a (3D, single grid) PL0T3I) XYZ+IBLANK file and 
write it out as a new XYZ+IBLANK file. 

• COMBINEQ C ombine several (31), single grid) PL0T3I) Q files into a new multiple 
grid Q file. 

• COMBINEX (ombine several (31), single grid) PL0T3D XYZ files into a new mul- 
t i]>le grid XYZ file. 

• COMBINEXB Combine several (31), single grid ) PL0T3I) XYZ+IBLANK files into 
a new multiple grid XYZ+IBLANK file. 

« ijk (; enerate a (31), single grid) PL0T31) XYZ file which is simply the computational 
grid, i.e. (x,y.z)=(i.j,k). Good for looking at flow quantities in the computational 
domain. 

• INT3D Interpolate a (3D, single grid) PLOT3I) Q file from one grid onto another. 
Old and new XYZ files may have IB LANK. Various options available on what to do 
if a new grid point isnb found within the old grid. Uses trilinear interpolation. 

• MIRRORQ Flip a (31). single grid) PL0T3D Q file about the x-. y-. or z-axis. 

• MIRRORX Flip a (31). single grid) PLOT3D XYZ file about the x-. y-. or z-axis. 

• PROPER2D Perform 21) grid line crossing check on a (21). single grid) PLOT3I) 
XYZ file. 

» PROPER3D Perform tetrahedron decomposition cell volume check on a (31), single 
grid) PLOT3D XYZ file. 

• PROPER3DN Perform tetrahedron decomposition grid crossing check on a (3D, 
single grid) PL0T3D XYZ file. 

• REFINEX Generate a new (3D. single grid) PL0T3D XY'Z file which is an integer 
refinement of an existing grid file. Uses parametric cubic interpolation. 

• ROTATEX Rotate a (3D. single grid) PL0T3D XYZ file about the x-, y-, or z-axis. 

• SCALEX Scale a (3D. single grid) PLOT3D XYZ file. 

• SCALEX Scale a (31), single grid) PL0T3I) XYZ+IBLANK file. 

• SPLITQ Split a (3D) multiple grid PL0T3I) Q file into separate single grid Q files, 
(’an skip grids if desired. 



248 


PLOTBC Tool Programs Description 


• SPLITX Split a (3D) multiple grid PL0T3D XYZ file into separate single grid XYZ 
files. Can skip grids if desired. 

• SPLITXB Split a (3D) multiple grid PLOT3D XYZ+IBLANK file into separate 
single grid XYZ+IBLANK files. Can skip grids if desired. 

• TRANSLATEX Translate a (3D. single grid) PLOT3D XYZ file. 

• TRANSLATEXB Translate a (3D. single grid) PLOT3D XYZ+IBLANK file. 

The UNIX make command may lie used to compile and link the PLOT3D tools as follows: 

2xxx/3xxx: make -f Makefile. i2 
CRAY 2: make -f Makefile. c2 
VAX/VMS: (3MAKEFILE . VMS 


7.6 PLOTBC Tool Programs Description 

In order to facilitate a graphical examination of an ADPAO07 boundary data file, a utility 
program called PLOTBC was created. The PLOTBC program reads in a user-specifiable 
ADPAC07 mesh and boundary data file and creates five PLOT3D- compatible command 
files. The five command files, in conjunction with the mesh file, permits the user to graphi- 
cally examine (using the PLOT 3D program) a number of features of the mesh construction 
and boundary condition specifications. This utility provides a rapid means of assessing the 
completeness of a boundary data file and provides a visual method for determining the 
characteristics of an ADPAC07 computational model. 

The PLOTBC 1 program is invoked by simply running the executable as follows: 


plotbc 

The appropriate path to the executable may also have to be specified if the executable file 
is not locally available. The user is then prompted for the ADPACV7 cast name as follows: 


Enter ADPAC case name: 

After entering the case name, the PLOTBC 1 program reads in the ADPAC'07 mesh and 
boundary data files, extracts the boundary conditions and organizes them into categories. 
Each category is then used to construct a PLOT3D command file which allows the user to 
visualize all boundary conditions in a common category. The resulting PLOT3D command 
files and their functions are listed in Table T.(j. Each of the ADPAC'07 boundary condi- 
tions identified by L J LOTBC is color-coded such that all the command files can be read 
sequentially, thus displaying all the boundaries at once. 

Once created, the PLOTBC command files may be used with PLO T3D by reading in the 
corresponding mesh file, and then invoking one or more of the scripts as shown below: 
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PLOTS!) Command Function 
File Name 


axes. com 
inlext.coni 
solid. coin 


out lino. com 
patch. com 


Grid index orientation 
Inflow/out flow boundaries 
Solid surfaces 
(viscous and inviscid) 

(rotating and non-rotating) 

Mesh block outline 

Inter- block PATCH boundaries 


Table 7.1: PLOTHC* command file names and boundary condition categories 
UNIX PR0MPT> plot3d 


Once t lie PLO LSI) program is initialized, the mesh file should be read in using the standard 
PLOTS!) commands, and then the command files may be invoked by a command such as: 


PL0T3D V3 : ^outline 

The action of the command file is to essentially define what is to be plotted. The actual 
plotting is not performed until the user enters the plot command at the PLOTS!) prompt. 
Additional details may be found in the PLOTS!) User's Manual [14]. 
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Appendix A 


ADPAC07 DISTRIBUTION AND 

DEMONSTRATION 

INSTRUCTIONS 

A.l Introduction 

This appendix describes the commands necessary to extract the source code and demo 
files from the ADPAC'Ol standard distribution and run a complete test case for a ducted 
fan employing multiple blade rows. The standard Al)PA(01 distribution is a compressed 
tar file which can be decoded into the various parts by a sequence of commands on any 
standard ( NIX system. The sequence listed below is intended to guide the user through 
the setup from the standard distribution up to and including a complete demonstration of 
a calculation for a ducted prop fan employing multiple blade rows. The command sequence 
listed below should work on most systems employing the UNIX operating system. Since 
portions of this process are inherently machine-dependent, the exact commands listed here 
are for a Silicon Graphics Workstation running the IRIX Operating System. Revision 4.0.1. 
Alternate commands will be listed when a significant machine dependence exists. 


A. 2 Extracting the Source Files 


The AI)PA('07 programs are distributed as a compressed tar file named 


adpacOlAar.Z 

This tar file requires roughly 22.0 megabytes of disk space. It should be possible to extract 
and run the code on any standard UNIX system from this distribution file. The first step 
necessary to extract the ADPAC07 programs is to uncompress the tar file with the com- 
mand: 


uncompress adpac07.tar.Z 
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This operation essentially replaces the compressed file adpaeOl Aar.Z with an uncompressed 
file adpaeOl Jar . The uncompressed tar file requires approximately 41.0 megabytes of disk 
space. 

The next step is to extract the individual files and directories from the adpaeOl. tar file. The 
tar command will create a subdirectory named adpaeOl in the current directory, so it is up 
to the user to move the adpaeOl. tar file to a suitable initial directory before extracting the 
embedded subdirectories. Once the tar file is properly placed, the ADPAC01 distribution 
may be extracted with the command 


tar xvof adpac07.tar 

(On some systems tar xvf adpac07.tar may be sufficient.) Execution of the UNIX list 
command Is -I will verify that the adpae directory has been created. The complete extraction 
process will require about 90.0 Megabytes of disk space (to hold the adpaeOl. tar file and 
the extracted contents). 

The uncompress and tar steps can be combined in a single operation on most l XIX systems 
by issuing the command 


zcat adpac07.tar.Z | tar xvf - 

This combined operation conserves overall disk space requirements during the extraction 
process. 


A. 3 Compiling the Source Code 


After extracting the source files, the user is naturally interested in compiling the source files 
for execution. A UNIX-compatible Make facility is provided for each of the ADPAC01 pro- 
grams. The Makefile which governs the compilation process is necessarily machine-dependent 
and requires that the user select from one of a number of preconfigured systems. The Make 
command is fully described in Section 3.4. If no option is specified in the make command, 
then the standard UNIX compilation is performed. 

In order to begin the compilation, it is first necessary to enter the adpae directory with the 
command: 


cd adpae 

At this point, several files and directories will be available. By entering the UNIX command 
Is -1, a listing of the individual directories can be obtained. The output of the Is command 
will look something like: 


README demo/ 


manual/ 


report/ sre/ 
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A descript ion of each of these listings is given below: 

README This file is a general description of the contents of the directory. 

demo This directory contains several geometry and flow input files for generating 
sample runs of the A DPA ('07 codes. 

manual This directory contains the LaTcX 'source code for this manual. If LaTc A 
is installed on your system, it is possible to reproduce this document (ex- 
cluding figures) with the command latex manual. The resulting device 
independent file manual. dvi may then be converted to PostScript or pre- 
viewed on screen through a number of widely available routines. 

report This directory contains the LaT( X source code for the final report outlin- 
ing the technical details of the ADPACU1 codes. II La D A is installed on 
your system, it is possible to reproduce the final report (excluding figures) 
with the command latex report. The resulting device independent file 
finaln port. dvi may then be converted to PostScript or previewed on screen 
through a number of widely available routines. 

src This directory contains all the FORTR AN source code for the A DPAC07 pro- 
grams including SETUP , ROTGRID . MAKEADGU ID. and A(T’I PLT-LCL. 

It is now possible to compile the ADPAC07 code by issuing the commands 

cd src/adpac 
make 

On a (’ray. the command make cray is appropriate, while on an IBM workstation make 
aix is appropriate. Other compilation options are available by typing nwkr hdp. The 
compilation of the executable module for I DPA ( '07 will require roughly 20 megabytes of 
disk space. 

A. 4 Running the Distribution Demonstration Test Cases 

Once the make facility has properly completed compiling the A DPA CO 7 source code, it is 
possible to run the test cases provided with the standard distribution. It is recommended 
that the sample cases be tested to verify proper compilation and extraction of the AD- 
PAC07 distribution. 

In order to run the demonstration cases, it is necessary to begin in the demo directory. 
From the . 1 DPA CQ7 source code directory, the Anno directory may be entered by issuing 
the command 

cd ../../demo 

Several test cases are provided with the standard distribution to illustrate the operation 
of the code for many different applications. The commands needed to run any demo are 
similar, so only the case listed under the directory nasa will be explained in detail here. 
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After entering the demo directory, an Is command will indicate that the following subdi- 
rectories (and possibly others) are available: 


bump/ markii/ nasa/ rotor67/ 

These subdirectories contain the ducted fan demonstration case described above (nasa/). 
as well as other demonstration test cases for the ADPAC07 code. To run the multiple blade 
row ducted fan demonstration case, enter the nasa subdirectory by issuing the command 
cd nasa. Now, the Is command reveals: 


nasa. input nasa.boundata nasa. mesh 

nasa . output . save nasa . converge . save 

The nasa directory contains the data to run a test case for the NASA 1.15 pressure ratio 
ducted fan. This geometry is representative of a 25:1 bypass ratio turbofan engine fan, and 
has been tested extensively both experimentally and numerically. This test case employs 
two blade rows (a rotor and a stator) and the multiple blade rows are treated using the 
circumferential averaging technique described in Section 2.2. The mesh corresponds to 
Standard Con figuration #10. and the mesh and appropriate mesh indices are illustrated in 
Figure A.l. The multiple-block mesh for this test case is contained in nasa.nieslu and may 
be viewed using the PLOTSD program. The flow Mach number is 0.75, and the calculation 
is performed at 100% design speed (9167 rpm). For the purposes of this demonstration, an 
in viscid calculation using 3 levels of multigrid has been configured. 

The next step in the solution process is to simply run the ADPAC07 program for this case. 
The standard input file nasa. input and the boundary data file nasa.boundata are pro- 
vided to run the program (these files are listed in this manual as sample files in Sections 
3.6 and 3.7). The steady flow solution is generated by issuing the command 


../../src/adpac/adpac <nasa. input >nasa.output 

The computation time required to generate the steady state solution may take up to four 
hours on a workstation-class computer. Once the steady flow solution has been generated, 
the Is command will reveal the following files: 


nasa. restart .new nasa.p3drel nasa.p3dabs 

nasa . converge nasa . input nasa . output 

nasa . converge . save nasa . output . save 

The file nasa. re st a rt.new contains the restart file necessary to continue this run from the 
point of termination. The files nasa.pSdabs and nasa.pSdrtl contain the absolute and rela- 
tive How PLOTSD flow variable information, respectively. The file nasa. out put is the new 
standard output file, and should be compared with the file nasa. out put. savt to verify that 
the program has performed the calculation correctly. It may be of interest to examine these 
steady flow results with PLOTSD at this point (see Ref. [14] for details). 
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NASA 1.15 Pressure Ratio Fan Test Case Description 

Axisymmetric Mesh View 



Mesh Block Structure 



Figure A.l: NASA 1.15 pressure ratio fan test case 
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NASA 1.15 Pressure Ratio Fan Test Case 
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Figure A. 2: ADPAC07 Convergence History for NASA 1.15 Pressure Ratio Fan Test Case 

A plot of the convergence history for this case is given in Figure A. 2. The "jumps” in the 
residual history are a result of the "full" multigrid startup procedure, and should not he 
considered inappropriate. 

The standard output file nasa.output should be compared with the listing provided in 
Section 3.10 to make sure that the code has performed the calculation properly. 
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